Freight MCP Servers 2026: En genomgång (Warp, CargoMART)

Server	Körs som	Verktyg	Bokningsbehov	Offertgiltighet	Omfattning
Warp `warp-agent-mcp`	stdio via npx	~23	API-nyckel	~72 timmar	Väg, eget nätverk
CargoAi CargoMART	värd	sök, citat, bok	kontoautentisering	kort fönster	Flygfrakt
freightutils-mcp	stdio via npx	~19	ingen (endast läsbar)	ej tillämpligt	Beräkningar, referens
Easyship	hosted eller stdio	priser, etiketter, spårning	API-nyckel	operatörsberoende	Paket

För några månader sedan skrev jag en introduktion till hur Modellkontextprotokollet mappas till ett frakt-API, inklusive en minimal server som du kan köra själv. MCP är den öppna standard som Anthropic publicerade i november 2024, och frakten var långsam med att anamma den tills början av 2026. Sedan dess har snacket tystnat och leveranserna har börjat. Warp publicerade warp-agent-mcp till npm den 16 april 2026 under en MIT-licens, CargoAi lanserade sin CargoMART-server den 5 juni 2026, och serverar för öppen källkod och paket kom ut samtidigt. Detta är uppföljningen jag ville läsa: en dissektion av vad som faktiskt skickades, var dessa fyra enas, och var designvalen tyst har avvikit. Om du inte har sett protokollgrunderna, börja med den introduktionen och återkom hit.

De servrar som faktiskt levererades

Warp warp-agent-mcp nådde npm den 16 april 2026, med MIT-licens, marknadsförd som den första MCP-servern för bokning av verklig frakt. Den exponerar ungefär 23 verktyg som spänner över sökning, prissättning, bokning och spårning mot Warps eget hanterade vägnät.
CargoAi CargoMART lanserades den 5 juni 2026 och lät en agent söka, offerera och boka flygfrakt inifrån Copilot, ChatGPT, Claude eller Gemini. Det är det tydligaste tecknet på att flygsidan rör sig, inte bara landtransporter.
freightutils-mcp är det open source-alternativet, ett TypeScript-paket med cirka 19 gratis verktyg. Det fokuserar mer på beräkningar och referensdata snarare än transaktioner på ett live-nätverk, vilket gör det till en ren sandlåda.
Easyship riktar sig till paket- och småförsändelsehantering via sina över 550 kuririntegrationer, och erbjuder priser, etikettkapning och spårning. Det är paketorienterat, så dess modelleringsantaganden skiljer sig från tung frakt.

Om man jämför sida vid sida skiljer sig de fyra åt i tre frågor: vad agenten kan göra utan autentiseringsuppgifter, hur länge ett pris gäller, och var servern körs.

Redskapsyta: vad agenten får göra

Varje server är en verktygslåda, och lådan berättar om tillverkarens avsikt. Warps cirka 23 verktyg är den bredaste uppsättningen eftersom den är byggd för att hantera transaktioner från början till slut, från kapacitetssökning till spårningsuppslag. CargoMART fokuserar på bokningsresan för flyg, med sökning, offert och bokning. freightutils stannar inom beräknings- och uppslagsterritoriet med sina 19 verktyg. Easyship optimerar för paketpris-till-etikett-loopen med priser, etiketter och spårning.

Tool surface: what the agent is allowed to do

När jag kartlägger dessa på ett fraktarbetsflöde så klustrar verktygen sig i fyra jobb: att hitta kapacitet, prissätta den, binda sig till den och bevaka att den flyttas. De två första läser bara, så de har låg risk. Att binda sig skriver till den verkliga världen och kostar pengar. Bevakning är återigen endast läsning men av högt värde, eftersom de flesta mänskliga timmar fortfarande går åt till att jaga status.

En agent upptäcker vad en server erbjuder genom MCP tools/list-metoden och anropar ett verktyg med tools/call, så namnen den läser tillbaka spelar roll. Namn som beskriver resultat som en dispatcher känner igen, som get_quote, book_shipment eller get_tracking, överlever kontakt med en riktig agent. Namn som läcker råa slutpunkter tvingar modellen att orkestrera "plumbing", och där smyger uppfunna parametrar in. Warp och CargoMART lutar båda åt resultatformade namn, vilket är en tyst signal om att de designades för agenter snarare än eftermonterades från en REST-specifikation.

Autentisering: öppen bokning, portad bokning

Det delade mönstret över de seriösa servrarna är det jag själv skulle ha valt. Verktyg för offert och referens är öppna eller har låg friktion, eftersom det är ofarligt och genuint användbart att låta en agent prissätta ett körfält. Bokning, avbokning och allt som rör fakturor ligger bakom en API-nyckel eller ett fullt OAuth-flöde. Warp, till exempel, läser sin nyckel från en lokal konfigurationsfil vid ~/.warp/config.json, så bokningsverktygen lyser upp först när du är autentiserad.

Authentication: open quoting, gated booking

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

Utan nyckeln kan agenten fortfarande utforska och ge citat. Med den kan agenten spendera pengar å dina vägnar. För desktop-användning är en statisk nyckel i en konfigurationsfil acceptabel. För en produktionsagent som bokar obemannat är en statisk nyckel en risk, och du vill ha OAuth 2.1 med PKCE och scope-begränsade, återkallbara tokens så att en komprometterad agent inte kan boka om eller avboka godtyckligt. Jag kommer att gå djupare in på detta i ett separat säkerhetsinlägg, eftersom fraktbokning förvandlar en vanlig prompt-injektion till en penninghändelse.

Citatets giltighetsfälla

Här är detaljen som ställer till det för team som är nya inom frakt. En offert är inte ett pris, det är ett pris med ett utgångsdatum. Warps offerter har till exempel ett giltighetsfönster på cirka 72 timmar, inte dagar. En agent som ger en offert på måndagen och försöker boka på fredagen kommer att misslyckas, och en naiv återförsöksloop kommer att fortsätta misslyckas samtidigt som den bränner tokens.

Så servern måste göra giltigheten maskinläsbar, och din agent måste respektera den. De bra implementationerna returnerar ett explicit utgångsdatum och en offert-referens, och bokningsverktyget kontrollerar båda. De svagare returnerar ett naket nummer och låter dig gissa. När du utvärderar en server, citera en bana, vänta och försök sedan att boka mot den inaktuella offerten. Hur det misslyckas, talar om hur mycket produktionshärdning som gjordes.

Transport: stdio kontra hostad HTTP

Protokollet definierar två transportmetoder, stdio och strömbart HTTP, och meddelandena är JSON-RPC 2.0 oavsett vilken metod som används. En lokal stdio-server, startad med npx, är perfekt för en utvecklare som kopplar en stationär assistent som Claude Desktop eller Cursor till sitt eget konto. Installationen är trivial och autentiseringsuppgifterna lämnar aldrig maskinen. En hostad HTTP-server körs som en tjänst, vilket är vad du behöver när en flotta av agenter delar åtkomst, när du vill ha central loggning och när du inte kan sprida API-nycklar över bärbara datorer.

freightutils och de npx-startade servrarna gör den lokala sökvägen enkel. Produktionsdistributioner lutar mot värdbaserad HTTP bakom en gateway som hanterar autentisering, begränsningar av frekvens och en revisionslogg. Ingen av dem är fel. Misstaget är att distribuera en stdio-prototyp i produktion och upptäcka att du inte har någon central överblick över vad dina agenter har bokat.

Vad en multiförsäljarmarknadsplats-server måste exponera

Här kommer mitt eget perspektiv in, eftersom vi driver en marknadsplats snarare än en enskild transportör, och modelleringsproblemet är genuint annorlunda. En server för en enskild transportör besvarar en fråga: kan jag flytta detta, och för hur mycket, i mitt nätverk. En marknadsplatsserver måste besvara en svårare fråga: vilka alternativ ska agenten välja bland många transportörer, och varför.

Det tvingar fram verktyg som en server med enkel bärare aldrig behöver. Agenten måste kunna jämföra erbjudanden, inte bara hämta ett. Den behöver en rankningssignal som kombinerar pris med transittid och tillgänglighet hos transportören, eftersom det billigaste anbudet på en rutt som ingen för närvarande trafikerar är en fälla. Den behöver ärlig tillgänglighet, så att agenten inte binder sig till kapacitet som redan är upptagen. Och den behöver den bokade sändningen för att stämma överens med en specifik transportör och referens, så att spårningen faktiskt löser sig. På en livlig rutt kan en agent se ett dussintal anbud och bara hitta tre eller fyra som går att boka den dagen, och i våra data är skillnaden mellan det billigaste anbudet och det billigaste bokningsbara anbudet verklig och återkommande. En marknadsplatsserver som döljer den skillnaden gör agenten en björntjänst. Lärdomen vi ständigt återupprepar är att ett pris utan tillgänglighet är marknadsföring, inte en bokning.

Hur man utvärderar en frakt-MCP-server

Om du väljer en, kör den här korta checklistan mot den aktiva servern istället för landningssidan.

Verktygsnamn. Beskriver de utfall som en dispatchcentral känner igen, eller exponerar de råa slutpunkter?
**Behörighetsgräns. Vad fungerar utan nyckel och vad kräver bokning? Finns det en väg till OAuth med begränsad omfattning för obemannad användning?**
**Citatgiltighet.** Returneras utgångsdatumet explicit, och avvisar bokningsverktyget ett förfallet citat rent?
Transport. Lokal stdio för skrivbord, hostad HTTP för en flotta. Stöder leverantören den du faktiskt behöver?
**Täckningsärlighet.** En enda operatör eller flera, och om flera, kan handläggaren se tillgänglighet och en ranking snarare än ett ogenomskinligt nummer?
Observerbarhet. Kan ni granska vad en agent har citerat och bokat i efterhand?

Marknaden flyttade från skrivartiklar till paket på ett enda kvartal, vilket är snabbt även med logistik-tech-mått mätt. Om du bygger bör grunderna plus denna genomgång vara tillräckligt för att koppla en agent till ett riktigt nätverk denna vecka. Om du köper kommer checklistan ovan att skilja en bokningsmotor från en demonstration. På en marknadsplats som HämtaTransport avgör samma principer om en agent kan lita på att spendera pengar, och den tilliten bygger på tillgänglighet och giltighet, inte på storleken på verktygslistan.

Vanliga frågor

Vad är en "freight MCP server"?

Det är en liten tjänst som exponerar fraktåtgärder, såsom offert, bokning och spårning, som verktyg en AI-assistent kan anropa genom Model Context Protocol, så att agenten integreras en gång istället för att lära sig varje speditörs API.

Vilka frakt-MCP-servrar finns 2026?

De mest anmärkningsvärda inkluderar Warps warp-agent-mcp för bokning av vägfrakt, CargoAis CargoMART för flygfrakt, öppen källkodsprojektet freightutils-mcp för beräkningar och referensdata, samt Easyship för paketpriser och etiketter.

Kan en AI-agent boka frakt utan en API-nyckel?

Vanligtvis inte. De flesta servrar låter en agent citera och slå upp data utan autentiseringsuppgifter, men boknings-, avboknings- och faktureringsåtgärder kräver en autentiserad nyckel eller en OAuth-token så att endast auktoriserade agenter kan spendera pengar.

Varför löper fraktkostnadskalkyler som returneras av en MCP-server ut?

Fraktpriser rör sig med kapacitet och bränsle, så en offert är bara giltig under ett kort fönster, ibland några timmar. Servern returnerar ett utgångsdatum, och agenten bör boka om en ny offert snarare än att försöka igen med en föråldrad.

Vad bör en MCP-server för en marknadsplats exponera som en för en enskild operatör inte gör?

Det ska låta agenten jämföra erbjudanden från olika transportföretag, se en ranking som blandar pris med transporttid och tillgänglighet, och stämma av en bokning mot ett specifikt transportföretag, eftersom den billigaste offerten inte alltid är den du faktiskt kan boka.