Какво е MCP сървър? Как работят MCP и MCP UI през 2026 г.

На 1 април 2025 г. Invariant Labs публикува инструмент с име add. Той приемаше две числа и връщаше сбора им. Описанието му обаче съдържаше и блок с маркер IMPORTANT, невидим в интерфейса на клиента, който казваше на модела да прочете ~/.cursor/mcp.json и ~/.ssh/id_rsa и да изнесе двата файла през излишен параметър. Моделът се подчини. Потребителят видя аритметика.

Тази демонстрация е най-полезното въведение в MCP сървърите, което познавам, защото показва и двете половини едновременно. Протоколът работи точно както е проектиран: AI клиентът откри инструмент, прочете описанието му и го извика. Моделът на доверие беше частта, която никой още не беше изградил.

Какво е MCP сървър

MCP сървърът е програма, която предоставя инструменти, данни и промптове на AI приложения чрез Model Context Protocol (MCP). Официалната документация определя MCP като „стандарт с отворен код за свързване на AI приложения с външни системи“. AI клиент като Claude, ChatGPT, Visual Studio Code или Cursor се свързва със сървъра, пита какво предлага и извиква тези възможности от името на потребителя.

Anthropic обяви MCP на 25 ноември 2024 г. заедно с шест готови сървъра: Google Drive, Slack, GitHub, Git, Postgres и Puppeteer. OpenAI го възприе през март 2025 г. Google DeepMind последва през април. През декември 2025 г. Anthropic дари протокола на Agentic AI Foundation, целеви фонд към Linux Foundation, съоснован от Anthropic, Block и OpenAI.

Проблемът е умножаването на връзките. Преди MCP всяко приложение с ИИ, което искаше достъп до GitHub, пишеше свой конектор, а всеки доставчик правеше връзка за всяко приложение. Десет модела и десет инструмента можеха да означават сто интеграции. MCP ги свежда до двадесет: всеки клиент внедрява протокола веднъж, всяка система излага един сървър.

Мислете за него като за транспортния контейнер на AI интеграциите. Преди контейнерите всяко пристанище товареше всеки товар на ръка, със свои кранове и свой екипаж. Контейнерът стандартизира кутията, така че всеки кораб, кран и камион можеше да превозва всеки товар. Той не стандартизира какво има вътре и никога не проверяваше съдържанието. MCP е същата сделка. Запомнете втората половина, тя се връща в раздела за сигурността.

Как работи MCP сървърът

Текущата спецификация, версия 2026-07-28, използва съобщения JSON-RPC 2.0 между три роли. Собственото ѝ описание е дълго три реда: хостовете са „LLM приложения, които инициират връзки“, клиентите са „конектори в хост приложението“, а сървърите са „услуги, които предоставят контекст и възможности“.

Хост, клиент, сървър

Хостът е приложението, в което пишете: Claude Desktop, IDE, Вашият собствен агент. В него работи по един клиент за всяка връзка със сървър. Сървърът седи от другата страна и говори с реалната система, независимо дали това е база данни Postgres, GitHub API или папка на Вашия диск. Хостът решава какво вижда моделът и какво трябва да одобри потребителят. Сървърът решава какво ще направи системата зад него.

1. Хост Claude Desktop · IDE · Вашият собствен агент

   показва инструментите на модела, иска съгласие от потребителя

2. Клиент по един за всяка връзка със сървър

   говори JSON-RPC през stdio или Streamable HTTP

3. MCP сървър инструменти · ресурси · промптове

   описва какво предлага и изпълнява извикванията

4. Системата зад него база данни · SaaS API · локални файлове

   върши работата

Инструменти, ресурси и промптове

Един сървър може да предлага три вида неща:

• Инструментите (tools) са функции, които моделът може да изпълни: create_issue, query_orders, send_email. Всеки има име, описание и JSON Schema за входните си данни.
• Ресурсите (resources) са контекст и данни, които потребителят или моделът чете: файл, схема на база данни, запис.
• Промптовете (prompts) са шаблонни съобщения и работни процеси, които потребителят може да избере, например „обобщи този pull request“.

Инструментите получават най-много внимание, защото действат. По същата причина носят и по-голямата част от риска.

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

Ревизията 2026-07-28 направи MCP протокол без състояние. Ръкостискането initialize вече го няма; всяка заявка носи версията на протокола и възможностите на клиента в поле _meta, а сървърите трябва да имплементират метод server/discover, за да може клиентът да попита предварително какво поддържат. Едно извикване на инструмент сега протича така:

1. Потребителят иска: създай тикет за този бъг

2. Стъпка 1

   Откриване

   • Клиентът може да извика server/discover за версии и възможности
3. Стъпка 2

   Списък с инструменти

   • tools/list връща имена, описания и схеми на входните данни
4. Стъпка 3

   Моделът избира инструмент

   • Хостът подава дефинициите на инструментите на модела
5. Стъпка 4

   Съгласие на потребителя

   • Според спецификацията хостът трябва да получи изрично съгласие, преди да извика който и да е инструмент
6. Стъпка 5

   Извикване

   • tools/call с аргументи, версия на протокола в _meta

7. Липсват данни? Сървърът връща input_required, клиентът повтаря с отговорите

   Стъпка 6

   Резултат

8. Резултатът се връща на модела като контекст

Стъпка 6 е нова в тази ревизия. Сървър, на който му трябва още информация, вече не изпраща собствена заявка обратно към клиента. Той връща резултат с маркер input_required, клиентът събира отговора и повтаря първоначалното извикване. Спецификацията нарича това модел Multi Round-Trip Request.

Транспорти: stdio и Streamable HTTP

Спецификацията определя два стандартни транспорта:

• stdio: клиентът стартира сървъра като подпроцес и обменя с него JSON-RPC съобщения, разделени с нов ред, през стандартния вход и изход. Така работят повечето локални сървъри и това означава, че сървърът работи на Вашата машина с Вашите права.
• Streamable HTTP: всяко съобщение е HTTP POST към една крайна точка, а отговорите се връщат като JSON обект или като поток от събития в рамките на заявката. Така работят отдалечените, хостваните сървъри.

По-старият транспорт HTTP+SSE е официално остарял. Ревизията 2026-07-28 премахна и сесиите на ниво протокол, както и заглавката Mcp-Session-Id; сървър, който се нуждае от състояние между извикванията, сега сам създава свой идентификатор и го получава обратно като обикновен аргумент на инструмента.

Авторизация

Авторизацията в MCP е незадължителна и се отнася само за HTTP. При stdio спецификацията казва, че сървърите трябва да вземат идентификационните данни от средата. При HTTP защитеният MCP сървър действа като OAuth 2.1 ресурсен сървър. Той трябва да публикува OAuth Protected Resource Metadata (RFC 9728), за да могат клиентите да намерят неговия сървър за авторизация. Клиентите трябва да посочат точния сървър, за който е токенът (индикатори на ресурси по RFC 8707). Сървърите трябва да отхвърлят всеки токен, който не е издаден за тях, а насоките за сигурност определят „token passthrough“, тоест препращането на токена на клиента без промяна към друго API, като изрично забранено.

Това последно правило е по-важно, отколкото изглежда. Сървър, който препраща всеки получен токен, се превръща в прокси за всеки, който държи токен.

Какво добавя MCP UI: сървъри, които връщат интерфейс

Текстовите отговори спират да работят в момента, в който потребителят трябва да сравни четиридесет реда, да попълни формуляр с дванайсет полета или да одобри пакет промени една по една. „MCP UI“ е името, под което хората търсят решението: сървърът връща интерактивен интерфейс, който се показва в AI клиента, до разговора.

Състоянието трябва да се опише точно. Идеята започва като общностния проект MCP-UI. OpenAI създава подобен механизъм в Apps SDK. Проектът MCP предлага общ стандарт с двете страни на 21 ноември 2025 г., а на 26 януари 2026 г. публикува MCP Apps като първото официално разширение на MCP. Пакетите MCP-UI вече прилагат тази спецификация и остават място за общностни подобрения.

Така че MCP UI днес означава MCP Apps. То е официално и е разширение, не част от ядрото на протокола. Разширенията са незадължителни: трябва да ги поддържат и клиентът, и сървърът, а документацията казва направо, че „поддръжката от хостовете зависи от клиента“. Документацията на MCP Apps изброява като поддържащи хостове Claude, Claude Desktop, VS Code GitHub Copilot, Microsoft 365 Copilot, Goose, Postman, MCPJam и Archestra.AI. Сървър, чиито инструменти връщат UI, все пак трябва да работи и с клиент, който показва само текст.

Механично то използва собствените градивни елементи на MCP:

1. Описанието на инструмента съдържа _meta.ui.resourceUri, което сочи към ресурс ui://.
2. Хостът изтегля този ресурс, HTML страница с нейните скриптове, и може да го зареди предварително, преди инструментът да бъде извикан.
3. Хостът го показва в изолиран iframe (sandbox), който не може да чете родителската страница, нейните бисквитки или хранилище.
4. Приложението и хостът общуват през postMessage на JSON-RPC диалект на MCP. Приложението може да иска извиквания на инструменти, а хостът решава кои да позволи.

Цената е реална. Вече доставяте уеб интерфейс в чуждо приложение, с политика за сигурност на съдържанието (CSP), която трябва да декларирате, с правила за показване, които не контролирате, и с текстов резервен вариант за всеки хост, който го игнорира. Печалбата е, че одобряването престава да бъде препис на чат. Списъкът с подходящи случаи в документацията завършва с „одобряване на разходни отчети, преглед на промени в кода или сортиране на проблеми“, и това е честната същност на въпроса: MCP UI е най-силен в решенията, не в украсата.

Пример с Tajo само за четене

Интерфейсът Alto MCP на Tajo включва query_contacts, който търси контакти, съхранени в свързаното работно пространство. Потърсете съществуващ контакт по имейл и проверете върнатия ID, състоянието на съгласието за имейл и времето на последно наблюдение. Отделният get_contact_topic_status чете абонаментите по теми.

Това са четения от работното пространство. Те не извличат нова снимка от доставчика, не стартират синхронизация и не изпращат съобщение. Не доказват и че всеки конектор работи. Разследвайте липсващи или остарели данни при източника. Празен резултат не доказва, че лицето липсва в Brevo.

Използвайте документацията за Tajo MCP, за да свържете поддържан клиент и да видите инструментите, действително изложени във Вашето упълномощено пространство. Интерактивният панел може да помогне, ако клиентът поддържа MCP Apps; текстовият резултат все пак трябва да обяснява изхода.

Извикване на инструмент не е устойчива синхронизация

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

След изтичане на времето четенето обикновено може да се повтори. Изпращане или плащане може вече да е станало. Запазете записа за изпълнение и изяснете резултата преди нов опит. Увереността на модела не дава разрешение и не прави повтора безопасен.

За конкретен запис на контакт вижте ръководството за API на Brevo. Кога изчислените полета се нуждаят от собствена поддържана синхронизация обяснява reverse ETL.

Сметката за сигурността идва заедно с протокола

Възражението заслужава да бъде изказано изцяло: „MCP дава на вероятностен модел списък с функции, които могат да трият данни и да изпращат имейли, и после се доверява на текст, написан от непознати, за да ги опише. Това не е стандарт за интеграция. Това е атака по веригата на доставки със спецификация.“ Повечето от това е вярно. Спецификацията е съгласна с предпоставката. Разделът ѝ за сигурност казва, че инструментите „представляват изпълнение на произволен код и с тях трябва да се борави с необходимата предпазливост“, че описанията на инструментите „трябва да се считат за ненадеждни, освен ако не са получени от доверен сървър“, и че MCP „не може да наложи тези принципи за сигурност на ниво протокол“.

Ето досегашната история:

• Отравяне на инструменти (tool poisoning). Разкритието на Invariant Labs от април 2025 г., инструментът add от по-горе. Същата публикация описа rug pull („издърпване на килима“), при който сървърът променя описанието на инструмент, след като сте го одобрили, и shadowing (засенчване), при който един злонамерен сървър пренаписва поведението на модела спрямо друг, доверен сървър.
• Компрометиране на локален сървър. През юли 2025 г. JFrog разкри CVE-2025-6514 в mcp-remote, версии от 0.0.5 до 0.1.15, която позволяваше на злонамерен сървър да изпълнява команди на машината на потребителя. Същото лято CVE-2025-49596 удари собствения MCP Inspector на Anthropic, който по подразбиране се доставяше без автентикация.
• Раздуване на обхватите. Официалните най-добри практики за сигурност назовават модела: токени с права files:* или admin:*, дадени предварително, защото сървърът е изброил всички обхвати, а клиентът е поискал всички.
• Официална загриженост. През май 2026 г. Агенцията за национална сигурност на САЩ (NSA) заяви, че „бързото разпространение на MCP е изпреварило развитието на неговия модел за сигурност“.

Къде възражението греши, е изводът. Решението никога не е било да спрем да свързваме модели със системи; екипите вече го правеха със сурови API ключове, поставени в промптове и скриптове, без никаква одитна следа. Решението е MCP сървърът да се третира като всяка друга привилегирована зависимост:

• Инсталирайте сървъри само от източници, на които бихте поверили същите идентификационни данни и извън MCP.
• Предпочитайте отдалечени сървъри с OAuth и тесни обхвати пред локални бинарни файлове с дългосрочни ключове.
• Изисквайте човешко одобрение за всеки запис и записвайте кой какво е одобрил.
• Фиксирайте версиите на сървърите и ги преглеждайте отново, когато описанието на инструмент се промени.
• Предоставяйте инструменти, оформени около задачи, а не цялото API; моделът не може да злоупотреби с крайна точка за изтриване, която никога не е била предоставена.

Протоколът стандартизира кутията. Проверката на товара все още е Ваша работа.

Да изградите MCP сървър или да използвате съществуващ

Публични каталози като mcp.so събират сървъри от общността, а много SaaS доставчици публикуват свои. Brevo например предлага MCP сървър, който е разделен и на отделни сървъри, така че агентът може да получи достъп до контактите без кампаниите. Решението е по-малко въпрос на усилие и повече въпрос на това кой трябва да определя формата на инструментите.

Кой MCP сървър да използва Вашият агент?

1. Доставчикът публикува сървър, който покрива задачата

   Използвайте сървъра на доставчика

   Той следва API и доставчикът го поддържа.

2. Една система, но Ви трябват по-малко или по-безопасни действия

   Използвайте го с ограничен обхват

   Дайте минимални обхвати и предоставете само групите инструменти, които агентът ползва.

3. Вътрешни данни или система без сървър

   Изградете малък сървър

   Няколко инструмента, оформени около задачи, върху Вашето собствено API, с Вашата автентикация.

4. Задачата обхваща две или повече системи

   Изградете или възприемете управляван слой

   Един набор от инструменти, правила за съгласие и одитна история за всички тях.

Изграждането на базов сървър е лесната част. С официален SDK работещ stdio сървър с един инструмент е работа за един следобед. Цената идва по-късно: OAuth за HTTP версията, остаряващи функции (ревизията 2026-07-28 обяви за остарели Roots, Sampling и Logging, както и Dynamic Client Registration) и постоянната работа по описания на инструменти, които моделът чете правилно. Обвиването на API по принципа една крайна точка, един инструмент е най-честата грешка. Всяко описание на инструмент е текст, който моделът трябва да прочете и прецени, така че кратък списък с инструменти, оформени около задачи, бие цялата повърхност на API.

MCP, API, интеграции и iPaaS

MCP не замества API. Почти всеки MCP сървър е обвивка около някое API. Работата все още се случва в API, с неговите лимити, модел на данните и особености. MCP променя кой може да го извика: модел, по време на изпълнение, който избира извикването по описание, вместо разработчик, който го е вписал твърдо в кода предварително.

Тази разлика очертава ясна граница спрямо другите две неща, с които MCP често се бърка:

• Интеграциите и iPaaS (основните платформи са сравнени тук) преместват данни по график или при задействане, детерминистично, независимо дали някой е в чат. Нощна синхронизация на 40 000 поръчки в CRM не бива да зависи от това дали моделът ще реши да направи 40 000 извиквания на инструменти.
• Обратният ETL (reverse ETL) изпраща моделирани данни от хранилище за данни обратно в оперативните инструменти. Какво е обратен ETL и кога е подходящ е отделна тема, и той е тръбопровод за данни, не разговор.
• MCP е за моментите, в които човек или агент трябва да попита, да провери или да действа в тези системи, при поискване.

Грешката върви и в двете посоки. Едни екипи изграждат MCP сървъри за масова синхронизация и получават бавни, скъпи и неповторими тръбопроводи. Други екипи изграждат внимателни интеграции, а после дават на AI асистента си суров API ключ, за да ги заявява, и получават неуправлявана задна врата.

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

За 22 месеца MCP стигна от шест референтни сървъра до проект на Linux Foundation, на който говорят Claude, ChatGPT, VS Code и Cursor. Свързването на модел със система вече е евтината част. Истинската работа е да решите какво му е позволено да прави там.