Cloudflare и Commerce.com описаха на 21 октомври WebMCP за близо 100 000 домейна. Това е съобщен обхват, не независимо установен ръст на продажбите.

Инструментите не са разрешение за покупка

Според описанието агентът получава структурирани инструменти в активната браузърна сесия, а човекът завършва checkout. Има възможност отделен търговец да се откаже. При неподдържан браузър или недостъпен MCP сървър е предвиден обичаен storefront. WebMCP остава експериментално предложение с ограничена браузърна достъпност, не окончателен универсален стандарт.

По-ранният Cloudflare анонс представя beta edge реализация, която добавя интерфейс към сайта чрез скрипт и toolpacks. Той е исторически контекст, не отделно ново издание от днес. Разграничението е важно: доставка на описания на инструменти, избор на действие от модела и обработка от търговската система са различни части на един процес.

Официалната BigCommerce MCP документация отделя B2C storefront инструменти от B2B Buyer Portal функции. Вторите зависят от наличния продукт и правата на удостоверения купувач. Guest достъпът до каталог и кошница не означава достъп до всички фирмени функции. Session sync може да свърже MCP с текущия клиентски контекст. Активирането се извършва от собственик на магазина с приемане на съответните условия; това не е настройка, която един агент следва сам да включва.

Какво се подобрява като архитектура

Нашият извод е, че ясно описаните инструменти могат да направят намерението по-лесно за проверка от поредица от неясни кликове. Заявка за търсене има конкретни аргументи; промяната на кошница има конкретен резултат. Това не доказва, че моделът е избрал правилния размер, продукт или действие. По-ясният интерфейс създава по-добри условия за проверка, но не извършва проверката вместо потребителя.

Предлагаме за първи пилот собствен тестов магазин с безобидни продукти и предварително зададени очаквания. Ако асистентът търси определен вариант, бихме сравнили намерението, подадените аргументи и получения SKU. После бихме сверили кошницата в нормалния интерфейс. Успешен отговор от инструмент не трябва да замества прегледа на действителното съдържание.

Отказът и непълният резултат също са част от процеса

Бихме проверили случай с липсващ вариант и случай с променена наличност. Очакването трябва да е агентът да съобщи ограничението, вместо без разрешение да подмени търсения продукт. При неясен резултат от добавяне в кошница първо бихме прочели нейното състояние. Повторно изпращане на действие само защото чатът не е получил ясен отговор може да произведе различен от желаното резултат.

Отделен тест би разгледал отказа на търговеца от WebMCP и неподдържан клиент. Бихме проверили дали посетителят запазва нормален път за работа и дали асистентът разбира, че няма инструмент. Това е редакционно предложен план, не извършен от нас тест върху магазини на Commerce.com.

Къде остава контролът

За екипа полезният договор е конкретен: какво може да се чете, какво може да се промени, какво вижда потребителят и коя стъпка изисква окончателно решение. Бихме запазили тези граници и при смяна на модела. Способността да се открие инструмент на страницата не е сама по себе си човешко разрешение за използването му.

Не бихме обявили търговска възвръщаемост само по наличието на интерфейс. За решение са нужни наблюдения върху собствен процес: правилно намерен вариант, вярна кошница и разбираемо предаване на контрола. Полезната следваща стъпка е ограничена проверка с ясна граница преди покупката.

Корица: концептуална AI илюстрация на подпомогнато пазаруване; не показва реален магазин или извършено плащане.

Проверено по посочените източници: 2026-10-23T06:29:40.415508+00:00.