Freight MCP Servers in 2026: Warp, CargoMART en Wat een Marketplace Server Moet Bieden

Server	Draait als	Tools	Boeking vereist	Offerte geldigheid	Bereik
Warp warp-agent-mcp	stdio via npx	~23	API key	~72 uur	Weg, eigen netwerk
CargoAi CargoMART	gehost	zoeken, offreren, boeken	account authenticatie	kort venster	Luchtvracht
freightutils-mcp	stdio via npx	~19	geen (alleen lezen)	niet van toepassing	Berekeningen, referentie
Easyship	gehost of stdio	tarieven, labels, tracking	API key	afhankelijk van vervoerder	Pakket

Een paar maanden geleden schreef ik een inleiding over hoe het Model Context Protocol wordt toegepast op een vracht-API, inclusief een minimale server die u zelf kunt draaien. MCP is de open standaard die Anthropic in november 2024 publiceerde, en de vrachtsector nam deze pas laat, begin 2026, over. Sindsdien is het praten gestopt en is het verzenden begonnen. Warp publiceerde warp-agent-mcp op 16 april 2026 onder een MIT-licentie op npm. CargoAi lanceerde zijn CargoMART-server op 5 juni 2026, en open-source en pakketservers verschenen ernaast. Dit is het vervolg dat ik wilde lezen: een analyse van wat er daadwerkelijk is uitgebracht, waar deze vier overeenkomen en waar de ontwerpkeuzes stilletjes uiteenlopen. Als u het protocol niet kent, begin dan met die inleiding en kom hier terug.

De servers die daadwerkelijk zijn uitgebracht

• Warp warp-agent-mcp bereikte npm op 16 april 2026, MIT-gelicentieerd, gepresenteerd als de eerste MCP-server voor het boeken van echte vracht. Het biedt ongeveer 23 tools voor zoeken, offreren, boeken en volgen binnen het eigen beheerde wegennetwerk van Warp.
• CargoAi CargoMART werd gelanceerd op 5 juni 2026, waardoor een agent luchtvracht kan zoeken, offreren en boeken vanuit Copilot, ChatGPT, Claude of Gemini. Het is het duidelijkste teken dat de luchtvaartsector in beweging is, niet alleen de wegtransportsector.
• freightutils-mcp is de open-source optie, een TypeScript-pakket met ongeveer 19 gratis hulpmiddelen. Het richt zich meer op berekeningen en referentiegegevens dan op transacties op een live netwerk, wat het een schone sandbox maakt.
• Easyship richt zich op pakket- en kleine vrachtzendingen via zijn meer dan 550 koeriersintegraties, met tarieven, labelaanmaak en tracking. Het is primair gericht op pakketten, dus de modelleringsaannames verschillen van die voor zware vracht.

Secuur bekeken, lopen de vier uiteen op drie vragen: wat de agent kan doen zonder inloggegevens, hoe lang een prijs geldig is en waar de server draait.

Tool-oppervlak: wat de agent mag doen

Elke server is een gereedschapskist, en de kist vertelt je de intentie van de leverancier. De ongeveer 23 tools van Warp zijn de breedste set omdat ze is gebouwd voor transacties van begin tot eind, van een capaciteitszoekopdracht tot een tracking lookup. CargoMART richt zich op de luchtboekreis en biedt search, quote en book. freightutils blijft in het berekenings- en lookupgebied met zijn 19 utilities. Easyship optimaliseert voor de parcel rate-to-label loop met tarieven, labels en tracking.

Wanneer ik deze in kaart breng op een vrachtworkflow, clusteren de tools in vier taken: capaciteit vinden, prijzen, ertoe verbinden en het volgen van de voortgang. De eerste twee lezen alleen, dus ze zijn risicoarm. Het vastleggen schrijft naar de echte wereld en kost geld. Het volgen is weer alleen lezen, maar van grote waarde, omdat het meeste menselijke werk nog steeds gaat naar het achtervolgen van de status.

Een agent ontdekt wat een server biedt via de MCP tools/list-methode en roept een tool aan met tools/call, dus de namen die het terugleest zijn belangrijk. Namen die resultaten beschrijven die een expediteur herkent, zoals get_quote, book_shipment of get_tracking, overleven contact met een echte agent. Namen die ruwe endpoints lekken, dwingen het model om de infrastructuur te orkestreren, en dat is waar verzonnen parameters in sluipen. Warp en CargoMART leunen beide naar uitkomstvormige namen, wat een stil signaal is dat ze zijn ontworpen voor agenten in plaats van zijn aangepast vanuit een REST-specificatie.

Authenticatie: open offertes, beperkt boeken

Het gedeelde patroon onder de serieuze servers is degene die ik zelf zou hebben gekozen. Offerte- en referentietools zijn open of hebben weinig frictie, omdat het laten prijzen van een baan door een agent onschadelijk en werkelijk nuttig is. Boeken, annuleren en alles wat met een factuur te maken heeft, bevindt zich achter een API-sleutel of een volledige OAuth-stroom. Warp leest bijvoorbeeld zijn sleutel uit een lokaal configuratiebestand op ~/.warp/config.json, dus de boektools lichten alleen op als u geauthenticeerd bent.

{
  "mcpServers": {
    "warp": {
      "command": "npx",
      "args": ["-y", "warp-agent-mcp"],
      "env": { "WARP_API_KEY": "your_key_here" }
    }
  }
}

Zonder de sleutel kan de agent nog steeds verkennen en offertes maken. Hiermee kan de agent namens u geld uitgeven. Voor desktopgebruik is een statische sleutel in een configuratiebestand acceptabel. Voor een productieagent die onbeheerd boekt, is een statische sleutel een risico, en wilt u OAuth 2.1 met PKCE en scope, intrekbare tokens, zodat een gecompromitteerde agent niet naar believen kan herboeken of annuleren. Hier ga ik dieper op in in een speciaal beveiligingsstuk, omdat vrachtboekingen een gewone prompt-injectie veranderen in een geldgebeurtenis.

De valkuil van offertegeldigheid

Hier is het detail dat teams die nieuw zijn in vracht, parten speelt. Een offerte is geen prijs, maar een prijs met een vervaldatum. De offertes van Warp hebben bijvoorbeeld een geldigheidsvenster van ongeveer 72 uur, geen dagen. Een agent die op maandag een offerte maakt en op vrijdag probeert te boeken, zal falen, en een naïeve herhalingslus zal blijven falen terwijl tokens worden verbruikt.

De server moet de geldigheid dus leesbaar maken voor machines, en uw agent moet deze respecteren. De goede implementaties retourneren een expliciete vervaldatum en een offerteverwijzing, en de boektool controleert beide. De zwakkere retourneren een kaal getal en laten u gokken. Wanneer u een server evalueert, maak een offerte voor een route, wacht en probeer vervolgens te boeken tegen de verlopen offerte. Hoe deze faalt, vertelt u hoeveel productieharding is toegepast.

Transport: stdio versus gehoste HTTP

Het protocol definieert twee transporten, stdio en Streamable HTTP, en de berichten zijn sowieso JSON-RPC 2.0. Een lokale stdio-server, gestart met npx, is perfect voor een ontwikkelaar die een desktopassistent zoals Claude Desktop of Cursor aan hun eigen account koppelt. De installatie is triviaal en de referenties verlaten de machine nooit. Een gehoste HTTP-server draait als een service, wat u nodig hebt wanneer een vloot van agenten de toegang deelt, wanneer u centrale logging wilt, en wanneer u geen API-sleutels over laptops kunt verspreiden.

freightutils en de met npx gestarte servers maken het lokale pad moeiteloos. Productiedistributies leunen naar gehoste HTTP achter een gateway die authenticatie, snelheidslimieten en een audit trail afhandelt. Geen van beide is verkeerd. De fout is het in productie brengen van een stdio-prototype en ontdekken dat u geen centraal overzicht heeft van wat uw agenten hebben geboekt.

Wat een server voor een multi-carrier marktplaats moet blootstellen

Hier komt mijn eigen perspectief, omdat wij een marktplaats exploiteren in plaats van een enkele vervoerder, en het modelleringsprobleem is echt anders. Een server voor één vervoerder beantwoordt één vraag: kan ik dit verplaatsen, en voor hoeveel, op mijn netwerk. Een marktplaats-server moet een moeilijkere vraag beantwoorden: welke optie moeten we bij vele vervoerders kiezen, en waarom.

Dat vereist tools die een server voor één vervoerder nooit nodig heeft. De agent moet aanbiedingen kunnen vergelijken, niet alleen één ophalen. Het heeft een rangschikkingssignaal nodig dat prijs combineert met transittijd en beschikbaarheid van vervoerders, omdat de goedkoopste offerte op een route die momenteel niemand bedient een valstrik is. Het heeft eerlijke beschikbaarheid nodig, zodat de agent zich niet committeert aan capaciteit die al weg is. En het heeft de geboekte zending nodig om terug te koppelen naar een specifieke vervoerder en referentie, zodat tracking daadwerkelijk oplost. Op een drukke route kan een agent tientallen offertes zien en slechts drie of vier die dag kunnen worden geboekt, en in onze gegevens is het gat tussen de goedkoopste offerte en de goedkoopste boekbare offerte reëel en terugkerend. Een marktplaats-server die dat gat verbergt, doet de agent geen plezier. De les die we blijven leren is dat een prijs zonder beschikbaarheid marketing is, geen boeking.

Hoe een vracht-MCP-server te evalueren

Als u er een kiest, loop deze korte checklist dan na op de live server in plaats van op de landingspagina.

1. Namen van tools. Beschrijven ze uitkomsten die een planner herkent, of tonen ze ruwe eindpunten?
2. Grenzen van inloggegevens. Wat werkt zonder sleutel, en wat vereist boeking? Is er een pad naar gescopeserde OAuth voor onbeheerd gebruik?
3. Geldigheid van offertes. Wordt de vervaldatum expliciet geretourneerd, en weigert de boekingsmodule een verlopen offerte netjes?
4. Transport. Lokale stdio voor desktop, gehoste HTTP voor een vloot. Ondersteunt de leverancier degene die u daadwerkelijk nodig hebt?
5. Eerlijkheid van dekking. Eén vervoerder of velen, en zo ja, kan de agent dan de beschikbaarheid en een rangschikking zien in plaats van één ondoorzichtig getal?
6. Observeerbaarheid. Kunt u achteraf auditen wat een agent heeft aangeboden en geboekt?

De markt verschoof van gedachtegangen naar pakketten in één kwartaal, wat zelfs naar maatstaven van logistiek-tech snel is. Als u bouwt, volstaan de inleiding en deze uiteenzetting om een agent deze week aan een echt netwerk te koppelen. Als u koopt, scheidt de bovenstaande checklist een boekingsmotor van een demo. Op een marktplaats zoals GetTransport bepalen dezelfde principes of een agent erop kan worden vertrouwd om geld uit te geven, en dat vertrouwen is gebouwd op beschikbaarheid en geldigheid, niet op de omvang van de toollijst.

Veelgestelde vragen

Wat is een vracht-MCP-server?

Het is een kleine service die vrachtacties, zoals het aanvragen van offertes, boeken en volgen, blootlegt als hulpmiddelen die een AI-assistent kan aanroepen via het Model Context Protocol, zodat de agent één keer integreert in plaats van elke vervoerders-API te leren.

Welke vracht MCP-servers bestaan er in 2026?

De meest opvallende zijn Warp's warp-agent-mcp voor wegvrachtboekingen, CargoAi's CargoMART voor luchtvracht, de open-source freightutils-mcp voor berekeningen en referentiegegevens, en Easyship voor pakkettarieven en labels.

Kan een AI-agent vracht boeken zonder een API-sleutel?

Meestal niet. De meeste servers laten een agent offertes aanvragen en gegevens opzoeken zonder inloggegevens, maar boekings-, annulerings- en factureringsacties vereisen een geauthenticeerde sleutel of een OAuth-token, zodat alleen geautoriseerde agenten geld kunnen uitgeven.

Waarom verlopen vrachtoffertes die door een MCP-server worden geretourneerd?

Vrachtprijzen bewegen met capaciteit en brandstof, dus een offerte is slechts geldig voor een kort tijdsbestek, soms een paar uur. De server retourneert een vervaldatum en de agent moet een nieuwe offerte boeken in plaats van een verlopen offerte opnieuw te proberen.

Wat moet een marktkplaats MCP-server blootgeven dat een enkele vervoerder niet doet?

Het moet de agent in staat stellen aanbiedingen van verschillende vervoerders te vergelijken, een rangschikking te zien die prijs, transittijd en beschikbaarheid combineert, en een boeking terug te koppelen aan een specifieke vervoerder, omdat de goedkoopste offerte niet altijd degene is die u daadwerkelijk kunt boeken.