MCP за уебсайт чатботове: Свързване на инструменти с OAuth и одобрения

MCP прави уебсайт чатботовете по-функционални - но само с ясни граници

MCP за AI чатботове не е магически щепсел, който изведнъж поверява произволни системи на даден уебсайт чатбот. Model Context Protocol описва по-скоро общ интерфейс, чрез който даден модел може да открива и извиква инструменти: например търсене в база със знания, заявка за тикет, логика за запазване на час или вътрешна проверка спрямо продуктови данни. Това е особено атрактивно за уебсайт чатботовете, тъй като много диалози не приключват с един отговор. Посетителите питат за статус на доставка, цени, начини за контакт, формуляри, наличност или следващи стъпки. Без инструменти ботът трябва само да обяснява. С инструменти той може, контролирано и проследимо, да извлича релевантни данни или да задвижва предварително подготвени действия.

Затова решаващият въпрос не е: Може ли чатботът да използва инструменти? Въпросът е: Кои инструменти има право да вижда в даден контекст, с кой токен да ги извиква, с кое човешко одобрение да ги изпълнява и с какво логване да ги обясни по-късно? Финалната MCP спецификация от 28 юли 2026 г. затяга именно тези оперативни въпроси. Тя прави ядрото без състояние (stateless), изисква съответните метаданни за всяка заявка (request) и прецизира как се свързват Remote HTTP авторизацията, OAuth, обхватите (scopes) и обвързването на токена с аудиторията (token-audience binding).

Какво променя спецификацията 2026-07-28 за екипите на уебсайтове

Най-важната архитектурна промяна е stateless core. Един MCP сървър не трябва да предполага, че предишни заявки по същата връзка вече са установили контекст, възможности на клиента (client capabilities) или сесия. Всичко, необходимо за обработката, трябва да се съдържа в текущия request. За разпределени уебсайт инфраструктури това е практично: заявките могат да попадат върху различни инстанции зад load balancers, edge gateways или worker платформи. За имплементациите обаче това означава също: без скрити предположения за транспортни сесии, без тихи права от предишна връзка и без чат разговора като граница на сигурността.

Всяка заявка се нуждае от задължителните _meta метаданни. Те включват по-специално версията на протокола и client capabilities; информацията за клиента е полезна за показване, логване и дебъгване, но не е подходяща като доказателство за сигурност. Ако даден уебсайт обслужва множество бот инстанции, езици или клиентски зони, този слой с метаданни трябва съзнателно да се валидира и логва. Той не замества бизнес авторизацията, но гарантира, че сървърът може да класифицира правилно заявките.

Списъците с инструменти са динамични, но не и произволни

tools/list в текущата спецификация е пагиниран и подлежащ на кеширане. Отговорите могат да съдържат указания за кеширане като ttlMs и cacheScope. В същото време подредбата трябва да остане детерминирана, докато основният набор от инструменти не се променя. Това е повече от козметично подобрение на производителността: когато каталозите с инструменти са стабилно сортирани, клиентите могат да ги кешират по-надеждно, а контекстът на модела остава по-спокоен.

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

Описанията на инструментите не са основа за доверие

MCP инструментите описват своето име, входни данни, незадължително изходни данни и анотации. Тези метаданни помагат на модела и потребителския интерфейс да разберат функцията. Те обаче не са котва за сигурност. Спецификацията ясно казва, че клиентите трябва да третират анотациите на инструментите като ненадеждни, освен ако не идват от доверени сървъри. Инструмент, който описва себе си като read-only, трябва все пак да бъде изграден от страна на сървъра така, че да не изпълнява странични ефекти с писане.

Това важи и за структурираните резултати. Един outputSchema помага да се валидират отговорите, а не просто да се подава свободен текст към модела. Въпреки това сървърите трябва да проверяват входните данни, да контролират достъпа, да поставят rate limits и да почистват изходните данни. Уебсайт чатботът не трябва да прехвърля резултатите от инструментите филтрирани директно във видимите отговори, особено когато са намесени външни API, клиентски данни или HTML съдържание.

OAuth: MCP сървърът е защитен ресурс

При Remote HTTP MCP разпределението на ролите е от решаващо значение. Един защитен MCP сървър действа като OAuth Resource Server. MCP клиентът действа от името на Resource Owner, т.е. обикновено потребител или организация. Authorization Server взаимодейства с потребителя, ако е необходимо, и издава access tokens. MCP сървърът трябва да предостави своите Protected Resource Metadata, за да могат клиентите да открият подходящия Authorization Server. Authorization Server предоставя поне един от методите за откриване: OAuth Authorization Server Metadata или OpenID Connect Discovery; MCP клиентът трябва да поддържа и двата.

За продуктовите екипи това означава: чатботът не трябва сам да управлява пароли, API ключове или чужди токени, когато е предвиден OAuth поток. Той трябва да отведе потребителя до ясно одобрение, след това да използва целеви access token и видимо да ограничи позволените с него инструменти. За регистрация на клиенти се предпочитат Client ID Metadata Documents; Dynamic Client Registration остава само за обратна съвместимост и е deprecated. Тъкмо при интеграции като календар, CRM, helpdesk, хранилище за документи или онлайн магазини това разделение е важно, защото същият разговор често преминава от обществени въпроси към действия, свързани с акаунта.

Токените трябва да са обвързани с целевия ресурс

Текущата спецификация за авторизация изисква Resource Indicators според RFC 8707. Клиентът трябва да зададе параметъра resource в заявките за авторизация и токени, като посочи каноничното URI на MCP сървъра, за който е предназначен токенът. MCP сървърът трябва да провери дали access token е издаден точно за неговия ресурс. Токените не трябва да се предават чрез query string, а принадлежат към Authorization Header.

Това обвързване с аудиторията (audience binding) предотвратява опасен пряк път: токен, предназначен за услуга A, не трябва да се приема или препраща към услуга B. Затова уебсайт чатботовете се нуждаят от чиста граница на токена за всеки MCP сървър и за всяка среда. Preview, Staging и Production не трябва да използват една и съща аудитория, ако представляват различни ресурси. По същия начин агрегатор, който обединява няколко MCP сървъра пред един модел, не трябва да смесва токени.

Scopes са UX и договор за сигурност

Scopes трябва да започват от малко. Спецификацията препоръчва използването на указания за scope от WWW-Authenticate предизвикателства и позволяването на step-up flow при липса на права. Практически това означава: даден посетител може първоначално да работи с инструменти за четене. Едва когато дадено действие изисква повече права, като създаване на тикет, запис на файл или подготовка на поръчка, системата целенасочено иска допълнителното одобрение.

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

Устойчива архитектура за уебсайт чатботове с MCP

Надеждната архитектура разделя модела, фасадата на инструментите и целевите системи. Уебсайт чатботът не комуникира директно с всеки външен доставчик, а с MCP клиент или gateway, който контролира версията на протокола, client capabilities, Auth статуса, rate limits и observability. Зад него стоят MCP сървъри за отделни интеграции или бизнес области. Всеки сървър декларира само инструментите, които са позволени за текущия request, и валидира повторно всяко извикване.

Фасадата на инструментите трябва да използва стабилни имена, тесни входни схеми и ясни изходни схеми. Имената на инструментите трябва да са достатъчно уникални, особено когато няколко сървъра предлагат сходни функции като search, create или lookup. При агрегатор помага пространството от имена (namespace) или префикс. Параметрите трябва да бъдат проектирани така, че моделът да не трябва да измисля сурови тайни данни. Ако даден процес се простира в няколко заявки, сървърът трябва да върне експлицитен, краткотраен handle и да го авторизира отново при всяко следващо извикване.

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

Чеклист за внедряване на MCP за AI чатботове

1. Създаване на инвентар на инструментите: Кои системи трябва да бъдат свързани, кои инструменти са само за четене, кои променят данни и кои изискват потвърждение от човек?
2. Дефиниране на scopes: Разделяне на правата по действия, а не по вътрешни екипи. Инструмент за справка за статус се нуждае от различни scopes от инструмент за създаване, промяна или изпращане.
3. Проверка на OAuth Discovery: Тестване на Protected Resource Metadata, Authorization Server Metadata, регистрация на клиенти и Redirect URIs за всяка среда.
4. Налагане на обвързване с аудиторията (Audience Binding): Приемане на токени само за каноничното URI на MCP сървъра, никога препращане за грешни ресурси и никога поставяне в URL адреси.
5. Правене на tools/list детерминиран: Тестване заедно на стабилно сортиране, пагинация, указания за кеширане и филтри за авторизация.
6. Поддържане на тесни схеми: Валидиране на входните данни, използване на структурирани изходни данни и деактивиране по подразбиране на автоматично мрежово зареждане на външни $ref цели; незадължително само с allowlist, timeout, ограничение на размера и логване.
7. Изграждане на одобрения в UI: Направете видими името на инструмента, целта, входните данни, целевата система, надграждането на scope (step-up) и опцията за отказ.
8. Закотвяне на Observability: Логване на Request ID, име на инструмента, scope, решение, грешка, латентност и тип резултат, без излишно съхраняване на чувствително съдържание.
9. Упражняване на пътищата за грешки: Третиране на 401, 403, изтекли токени, липсващи scopes, неизвестни handles, timeouts и отказани одобрения като нормални продуктови състояния.
10. Започване от малко: Първо пускане на живо на един или два инструмента с нисък риск само за четене, след това поетапно добавяне на step-up, действия за писане и допълнителни интеграции.
Scope

Типични грешки при реализацията

Най-честата грешка е твърде широк първи токен. Ако уебсайт чатботът получи пълни права за писане веднага след първото влизане, всяко решение на модела става по-рисково. За предпочитане е минимален начален scope с целеви step-up. Втората грешка е каталог с инструменти, който се състои от имена на вътрешни системи вместо от намерения на потребителя. Един модел работи по-надеждно с ясни, точно описани действия, отколкото с генерични крайни точки с общо предназначение.

Третата грешка е липсата на разделение между доверието в модела и доверието в сървъра. Моделът може да предложи действие, но сървърът решава дали входните данни са валидни, дали токенът съвпада и дали има одобрение. Четвъртата грешка е липсата на проследимост. Ако по-късно не е ясно кой инструмент с кой scope какви данни е прочел или променил, нито поддръжката, нито сигурността могат да се управляват правилно.

Задълбочаване по темата

Тази статия разглежда интеграционния слой на MCP: stateless core, tools/list и HTTP OAuth. Следните статии задълбочават общата сигурност и работа на инструментите: За модела на правата вижте Безопасно използване на инструменти с права и потвърждения при AI чатботове. За конкретни извиквания на инструменти си струва да прочетете Безопасно проектиране на извиквания на инструменти в AI чатботове. Ако искате резултатите от инструментите да останат машинно четими, вижте Валидиране на структурирани изходни данни от AI чатботове. За експлоатация и отстраняване на грешки техническото продължение е Observability за AI чатботове: Traces, Retrieval и инструменти.

Официални източници

Професионалната основа е финалната MCP спецификация 2026-07-28: страницата за MCP Tools, страницата за MCP Authorization, официалният публикация The 2026-07-28 Specification и Base Protocol Overview.

Заключение

MCP за AI чатботове става ценен тогава, когато екипите на уебсайтове го разбират не като отворена кутия с инструменти, а като контролиран интеграционен слой. Спецификацията 2026-07-28 се вписва добре в модерната уеб инфраструктура: stateless заявки, подлежащи на кеширане списъци, рутируеми HTTP хедъри и експлицитна авторизация за всеки ресурс. В същото време тя прави отговорността по-ясна. Предлаганите инструменти трябва да съответстват на текущия токен, чувствителните операции се нуждаят от човешки контрол, а всяко извикване трябва да се валидира от страна на сървъра.

Прагматичният старт е малък: един инструмент за четене, тесен scope, ясен текст за съгласие, детерминирано откриване на инструменти (tool discovery) и добри логове. След това могат да се свързват допълнителни инструменти, без чатботът да се превръща в черна кутия. Така уебсайт чатботът се развива не като неконтролиран агент, а като проследим асистент, който има право да използва точно тези системи, които са одобрени за текущия потребител и текущата задача.