Freight MCP Servers 2026: Розбір (Warp, CargoMART)

Сервер	Працює як	Інструменти	Потреби для бронювання	Термін дії ціни	Сфера застосування
Warp `warp-agent-mcp`	stdio через npx	~23	API ключ	~72 години	Дорога, власна мережа
CargoAi CargoMART	хостинг	пошук, ціна, бронювання	автентифікація облікового запису	коротке вікно	Авіаперевезення
freightutils-mcp	stdio через npx	~19	немає (тільки для читання)	не застосовується	Розрахунки, довідка
Easyship	хостинг або stdio	тарифи, етикетки, відстеження	API ключ	залежить від перевізника	Посилки

Кілька місяців тому я написав посібник про те, як протокол Model Context Protocol відображається на API вантажоперевезень, включно з мінімальним сервером, який ви можете запустити самостійно. MCP — це відкритий стандарт, опублікований Anthropic у листопаді 2024 року, і галузь вантажоперевезень повільно приймала його до початку 2026 року. Відтоді розмови припинилися, а робота почалася. Warp опублікував warp-agent-mcp в npm 16 квітня 2026 року під ліцензією MIT, CargoAi запустила свій сервер CargoMART 5 червня 2026 року, а разом з ними з'явилися сервери з відкритим кодом та для посилок. Це продовження, яке я хотів прочитати: розбір того, що насправді було випущено, де ці чотири домовилися, і де вибір дизайну тихо розійшовся. Якщо ви ще не бачили основ протоколу, почніть з того посібника і повертайтеся сюди.

Сервери, які насправді були випущені

Warp warp-agent-mcp з'явився в npm 16 квітня 2026 року, ліцензований MIT, позиціонується як перший сервер MCP для бронювання реальних вантажоперевезень. Він надає приблизно 23 інструменти для пошуку, ціноутворення, бронювання та відстеження в власній керованій мережі Warp.
CargoAi CargoMART був випущений 5 червня 2026 року, дозволяючи агенту шукати, оцінювати та бронювати авіаперевезення з Copilot, ChatGPT, Claude або Gemini. Це найчіткіший знак того, що напрямок авіаперевезень рухається, а не тільки дорожніх.
freightutils-mcp — це варіант з відкритим кодом, пакет TypeScript з приблизно 19 безкоштовними утилітами. Він більше орієнтований на розрахунки та довідкові дані, аніж на транзакції в реальній мережі, що робить його чистою пісочницею.
Easyship орієнтований на посилки та невеликі пакети через свої понад 550 інтеграцій з кур'єрами, надаючи тарифи, створення етикеток та відстеження. Він насамперед для посилок, тому його припущення щодо моделювання відрізняються від важких вантажів.

Порівнюючи ці чотири сервери, ми бачимо розбіжності щодо трьох питань: що агент може робити без облікових даних, як довго діє ціна та де працює сервер.

Доступні інструменти: що дозволено агенту

Кожен сервер — це набір інструментів, і цей набір демонструє наміри постачальника. Warp має приблизно 23 інструменти, що є найбільшим набором, оскільки він розроблений для повного циклу транзакцій, від пошуку потужностей до перевірки статусу відстеження. CargoMART зосереджений на процесі бронювання авіаперевезень, надаючи пошук, ціноутворення та бронювання. freightutils залишається в галузі розрахунків та пошуку за допомогою своїх 19 утиліт. Easyship оптимізований для циклу від тарифу до етикетки для посилок, пропонуючи тарифи, етикетки та відстеження.

При відображенні цих інструментів на робочому процесі вантажоперевезень, вони групуються за чотирма завданнями: пошук потужностей, їх оцінка, резервування та відстеження переміщення. Перші два — це лише читання, тому вони низькоризиковані. Бронювання — це запис у реальний світ і витрата грошей. Відстеження — знову читання, але високоцінне, оскільки більша частина людського часу все ще витрачається на перевірку статусу.

Агент дізнається, що пропонує сервер, за допомогою методу MCP tools/list, і викликає інструмент за допомогою tools/call, тому назви, які він зчитує, мають значення. Назви, що описують результати, які розпізнає диспетчер, такі як get_quote, book_shipment або get_tracking, витримують взаємодію з реальним агентом. Назви, які розкривають сирі кінцеві точки, змушують модель оркеструвати сполучні шляхи, і саме тут з'являються вигадані параметри. Warp і CargoMART обидва схиляються до назв, сформованих за результатами, що є тихим сигналом того, що вони були розроблені для агентів, а не перероблені зі специфікації REST.

Аутентифікація: відкрите квотування, обмежене бронювання

Спільний шаблон для всіх серйозних серверів — це той, який я сам би обрав. Інструменти для квотування та створення довідників є відкритими або мають низький поріг входу, оскільки дозвіл агенту оцінити вартість перевезення вантажу є безпечним і справді корисним. Бронювання, скасування та все, що стосується рахунку-фактури, вимагає API-ключа або повного потоку OAuth. Наприклад, Warp зчитує свій ключ з локального конфігураційного файлу за адресою ~/.warp/config.json, тому інструменти бронювання активуються лише тоді, коли ви автентифіковані.

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

Без ключа агент все ще може досліджувати та квотувати. З ключем агент може витрачати ваші гроші від вашого імені. Для настільного використання статичний ключ у конфігураційному файлі є прийнятним. Для виробничого агента, який бронює без нагляду, статичний ключ є вразливим місцем, і вам потрібен OAuth 2.1 з PKCE, а також обмежені, відкличні токени, щоб скомпрометований агент не міг повторно бронювати або скасовувати за бажанням. Я заглиблюся в це в спеціальній статті з безпеки, оскільки бронювання вантажів перетворює звичайне вливання команд на грошову подію.

Пастка терміну дії цитати

Ось деталь, яка кусає команди, нові для вантажних перевезень. Цитата — це не ціна, а ціна з терміном дії. Наприклад, цитати Warp мають вікно дії близько 72 годин, а не днів. Агент, який квотує в понеділок і намагається забронювати в п'ятницю, зазнає невдачі, а наївний цикл повторних спроб продовжуватиме зазнавати невдач, спалюючи токени.

Отже, сервер повинен зробити термін дії машиночитаним, а ваш агент повинен його поважати. Хороші реалізації повертають явний термін дії та посилання на цитату, а інструмент бронювання перевіряє обидва. Слабші повертають просте число і залишають вас в здогадках. Коли ви оцінюєте сервер, квотуйте маршрут, зачекайте, а потім спробуйте забронювати за застарілою цитатою. Те, як він зазнає невдачі, покаже вам, наскільки далекоглядною була підготовка до виробництва.

Транспорт: stdio проти розміщеного HTTP

Протокол визначає два види транспорту: stdio та Streamable HTTP, і обидва повідомлення є JSON-RPC 2.0. Локальний сервер stdio, запущений за допомогою npx, ідеально підходить для розробника, який підключає настільний помічник, такий як Claude Desktop або Cursor, до свого облікового запису. Налаштування тривіальне, а облікові дані ніколи не покидають комп'ютер. Розміщений HTTP-сервер працює як служба, що вам потрібно, коли парк агентів спільно використовує доступ, коли ви хочете централізоване ведення журналу, і коли ви не можете розкидати API-ключі по ноутбуках.

freightutils та сервери, запущені через npx, роблять локальний шлях легким. Виробничі розгортання схиляються до розміщеного HTTP за шлюзом, який обробляє автентифікацію, обмеження швидкості та аудит. Жоден з них не є неправильним. Помилка полягає в тому, щоб відправити прототип stdio у виробництво та виявити, що у вас немає центрального огляду того, що забронювали ваші агенти.

Що повинен надавати сервер ринку з багатьма перевізниками

Ось тут і вступає в силу моя власна перспектива, оскільки ми керуємо ринком, а не одним перевізником, і проблема моделювання справді відрізняється. Сервер одного перевізника відповідає на одне запитання: чи можу я перевезти це, і за скільки, у своїй мережі. Сервер ринку повинен відповісти на складніше запитання: серед багатьох перевізників, яку опцію повинен вибрати агент і чому.

Це змушує інструменти, які сервер для одного перевізника ніколи не потребуватиме. Агент повинен мати змогу порівнювати пропозиції, а не просто отримувати одну. Йому потрібен сигнал ранжування, що поєднує ціну з часом у дорозі та наявністю перевізника, оскільки найдешевша пропозиція на маршруті, який ніхто не обслуговує, є пасткою. Йому потрібна чесна доступність, щоб агент не брався за потужності, яких вже немає. І йому потрібно, щоб заброньоване відправлення узгоджувалося з конкретним перевізником та посиланням, щоб відстеження дійсно працювало. На зайнятому маршруті агент може побачити дюжину пропозицій і знайти лише три-чотири, які можна забронювати того дня, і в наших даних розрив між найдешевшою пропозицією та найдешевшою можливою для бронювання пропозицією є реальним і повторюваним. Сервер маркетплейсу, який приховує цей розрив, робить послугу агенту ведмежою послугою. Урок, який ми постійно засвоюємо, полягає в тому, що ціна без доступності – це маркетинг, а не бронювання.

Як оцінити сервер MCP для вантажних перевезень

Якщо ви обираєте один, перевірте цей короткий список на реальному сервері, а не на цільовій сторінці.

Назви інструментів. Чи описують вони результати, визнані диспетчером, чи надають доступ до необроблених кінцевих точок?
Межа повноважень. Що працює без ключа, а що вимагає бронювання? Чи є шлях до OAuth з визначеною областю для роботи без нагляду?
Термін дії пропозиції. Чи повертається термін дії явно, і чи відхиляє інструмент бронювання недійсні пропозиції коректно?
Транспорт. Локальний stdio для настільного комп’ютера, розміщений HTTP для флоту. Чи підтримує постачальник той, який вам насправді потрібен?
Чесність охоплення. Один перевізник чи багато, і якщо багато, чи може агент бачити доступність та ранжування, а не одне непрозоре число?
Спостережуваність. Чи можете ви перевірити, що агент цитував і бронював після факту?

Ринок перейшов від теоретичних роздумів до готових пакетів за один квартал, що є швидким навіть за стандартами логістичних технологій. Якщо ви розробляєте, введення та цей розбір будуть достатніми для підключення агента до реальної мережі цього тижня. Якщо ви купуєте, наведений вище контрольний список дозволить відрізнити механізм бронювання від демо. На маркетплейсі, такому як GetTransport, ті ж принципи визначають, чи можна довіряти агенту витрачати гроші, і ця довіра будується на доступності та дійсності, а не на розмірі списку інструментів.

FAQ

Що таке сервер MCP для вантажних перевезень?

Це невеликий сервіс, який надає функції вантажних перевезень, такі як цитування, бронювання та відстеження, як інструменти, які штучний інтелект-асистент може викликати через протокол Model Context Protocol, завдяки чому агент інтегрується один раз замість того, щоб вивчати API кожного перевізника.

Які сервери MCP для вантажних перевезень існують у 2026 році?

Серед помітних – warp-agent-mcp від Warp для бронювання автомобільних вантажів, CargoMART від CargoAi для авіаперевезень, відкритий freighutils-mcp для розрахунків та довідкових даних, а також Easyship для тарифів та етикеток для посилок.

Чи може агент зі штучним інтелектом бронювати вантажі без ключа API?

Зазвичай ні. Більшість серверів дозволяють агенту отримувати пропозиції та шукати дані без облікових даних, але бронювання, скасування та виставлення рахунків вимагають автентифікованого ключа або токена OAuth, щоб лише авторизовані агенти могли витрачати гроші.

Чому пропозиції щодо вантажних перевезень, повернуті сервером MCP, закінчуються?

Ціни на вантажі змінюються залежно від потужностей та палива, тому пропозиція дійсна лише короткий проміжок часу, іноді кілька годин. Сервер повертає термін дії, і агент повинен повторно забронювати нову пропозицію, а не повторювати спробу з недійсною.

Що повинен надавати сервер MCP маркетплейсу, чого не надає сервер для одного перевізника?

Він повинен дозволяти агенту порівнювати пропозиції різних перевізників, бачити ранжування, що поєднує ціну з часом у дорозі та доступністю, а також узгоджувати бронювання з конкретним перевізником, оскільки найдешевша пропозиція не завжди є тією, яку ви можете фактично забронювати.