MCP архитектура: пълен технически анализ с диаграми

MCP архитектурата е основният набор от компоненти и комуникационни правила, които правят възможен MCP (Model Context Protocol). MCP е стандарт с отворен код, а MCP архитектурата е базовата инфраструктура, върху която той работи.

Всяка MCP архитектура съдържа три основни компонента и е изградена около тях: хост, клиент и сървър. Комуникационната рамка на MCP често се описва като съставена от слой за данни и транспортен слой. Слоят за данни е наборът от правила за форматиране на съобщенията (MCP заявките се изпращат в JSON-RPC 2.0). Транспортният слой пренася тези съобщения, като за външни връзки използва Streaming HTTP.

MCP архитектурата е сървърна рамка, която имплементира Model Context Protocol – отворен стандарт за свързване на AI модели с инструменти, ресурси като бази данни и подкани, които разширяват входния контекст. Те се наричат общо „примитиви“. В крайна сметка MCP архитектурата позволява на LLM да откриват кои инструменти са налични и да изпълняват работни процеси, без да са необходими редовни актуализации от страна на клиента.

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

Откакто беше представена от Anthropic, MCP архитектурата намери широко приложение в AI работните процеси. Това се дължи до голяма степен на факта, че тя заменя системи, изискващи повече поддръжка, като например изградените около множество API връзки, без да се жертва производителността. Тъй като цялата налична функционалност е зад MCP сървъра, е необходима само една връзка, а актуализациите и допълненията са незабавно достъпни за клиентското приложение.

MCP дава на LLM начин да откриват и извикват инструментите, подканите и ресурсите, достъпни за тях – било в локалната система на хост приложението, било от външен доставчик.

При инструментите, които осигуряват достъп до външна функционалност, откриването включва извикване tools/list от хоста към MCP сървъра, за да се установи кои инструменти са налични. След това LLM (или в някои случаи хостът) може да прочете описанията на наличните инструменти и да ги заяви при нужда. Подканите и ресурсите използват подобен процес.

Диаграма на компонентите на MCP архитектурата: хост, съдържащ LLM, оркестратор и клиент, се свързва с MCP сървър в две стъпки – откриване и след това заявки, а MCP сървърът предоставя инструменти, ресурси и подкани.

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

Хост приложението е централната платформа за оркестрация и се свързва с LLM. Добре познати инструменти като Perplexity и Claude Desktop могат да действат като хостове в MCP система.

При прост работен процес потребителят задава въпрос чрез чат интерфейса. След това компонентът оркестратор на хоста добавя контекст към въпроса, като съобщава на LLM кои MCP примитиви са налични, заедно с описание на техните възможности.

Клиентът е софтуерен компонент в AI приложението. MCP предоставя стандартен интерфейс, чрез който клиентът комуникира с вътрешни и външни MCP сървъри въз основа на инструкциите на хоста или LLM. Неговата задача е да установи връзка, да форматира JSON-RPC съобщения, да изпраща заявки и да получава отговори.

Термините „MCP хост“ и „MCP клиент“ понякога се използват като взаимозаменяеми. Разграничението обаче е полезно, защото хост като Perplexity може да оркестрира няколко MCP клиента едновременно. Сложен AI работен процес може да изисква достъп до десетки или дори стотици отделни MCP сървъри, като всеки от тях ще използва отделна връзка.

Диаграма на MCP хост, например Perplexity, който оркестрира три MCP клиента, всеки свързан със собствен MCP сървър, например база данни, файлове или външен API.

Сървърът предоставя всички инструменти, които AI-базираният инструмент може да използва. От архитектурна гледна точка MCP сървърът интерпретира входящата заявка и при нужда се свързва със заявените примитиви.

MCP сървърите могат да предоставят достъп до три категории примитиви:

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

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

Слоят за данни в MCP архитектурата е наборът от правила, които определят как се форматират заявките, отговорите и известията. Стандартният език за съобщенията е JSON-RPC.

Всяка MCP архитектура следва основен процес: (1) инициализация и откриване от хоста, (2) отговор от MCP сървъра и (3) извикване от хоста (понякога решено от LLM), като всеки етап представлява отделно JSON съобщение.

Диаграма на слоя за данни в MCP: потребител изпраща подкана до хост приложението, където LLM работи с MCP клиента; клиентът изпраща заявка до MCP сървъра (инструменти, ресурси, подкани) и получава резултат, а хостът връща отговор на потребителя.

Нека разгледаме как работи откриването на инструменти чрез два примера (те могат да се отнасят и за ресурси или подкани):

Откриване на инструменти преди генерирането от LLM: Хостът инициира MCP клиента, който изпраща заявка tools/list (списъкът на MCP сървъра с налични инструменти). LLM преглежда списъка по време на процеса на генериране и определя дали е необходим конкретен инструмент, ресурс или подкана.
Предоставяне на LLM на възможност да изпълни търсене: В агентна система хостът добавя опция за откриване, като например search-tools, към входния контекст и LLM може да заяви търсене при нужда.

Инструментите, които в общи линии са функционалности на външни приложения, обикновено се избират от LLM или хоста. Ресурсите и подканите обикновено се заявяват по искане на потребителя или от хоста.

Ето как изглежда заявка tools/list към MCP сървър от въображаемо приложение за бележки:

json

{
  "jsonrpc": "2.0",
  "id": 101,
  "method": "tools/list",
  "params": {
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

В този пример “id”:101 идентифицира заявката чрез ID, така че клиентът да може да съпостави отговорите, а полето “params” съдържа допълнителна информация за клиента, като името на клиента (notes-app-client) и възможностите му.

В отговор MCP сървърът ще върне дефиниции на инструменти, които включват имената на наличните инструменти и свързаните с тях подробности. Например списъкът може да включва инструмент add-task, който позволява на приложението за бележки да създава задачи в свързано приложение за управление на задачи или календар, като присвоява на всяка задача заглавие и приоритет.

Ето как може да изглежда една заявка:

json

{
  "jsonrpc": "2.0",
  "id": 202,
  "method": "tools/call",
  "params": {
    "name": "add-task",
    "arguments": {
      "title": "Review the draft",
      "priority": "medium"
    },
    "_meta": {
      "io.modelcontextprotocol/protocolVersion": "2026-07-28",
      "io.modelcontextprotocol/clientInfo": {
        "name": "notes-app-client",
        "version": "0.1.0"
      },
      "io.modelcontextprotocol/clientCapabilities": {}
    }
  }
}

Полето “method” указва на MCP сървъра, че това е извикване на инструмент, “name” посочва кой инструмент да се извика, а “arguments” предоставя необходимите входни данни.

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

MCP има два транспортни механизма:

Стандартен вход/изход: Използва се, когато MCP сървърът работи в същата локална среда като хост приложението. Клиентът записва JSON заявката в стандартния вход на сървъра. Сървърът я прочита, изпълнява заявената операция и записва отговора в стандартния изход.
Streamable HTTP: Когато MCP сървърът работи извън хост приложението, MCP клиентът изпраща заявки до сървъра чрез HTTP POST. Сървърът отговаря или с едно JSON съобщение, или с поток Server-Sent Events (SSE) – постоянен канал за „слушане“, който му позволява да връща множество съобщения с течение на времето.

Многонаемателската MCP архитектура е вид имплементация, която може да обслужва едновременно множество потребители (наематели).

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

Тя работи на същия основен принцип като стандартната MCP архитектура, но заявките на отделните потребители се изпълняват в собствено работно пространство (дори ако това включва споделени ресурси) и се удостоверяват поотделно. Тя е често срещана в корпоративни сценарии, като споделените ресурси често се предпочитат, защото изпълнението на множество MCP сървъри би било ненужно скъпо.

Как изглежда една цялостна MCP заявка на практика? Има осем основни етапа, всеки от които включва отделен компонент на архитектурата.

Блок-схема на цялостна MCP заявка в осем стъпки: откриване на инструменти, потребителски вход, обработка от модела, избор на инструмент, заявка, изпълнение на инструмента, резултат и генериране на отговор.

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

Откриване на инструменти: Приложението за бележки (хостът) използва своя MCP клиент, за да поиска наличните инструменти на сървъра чрез заявка tools/list. Сървърът връща техните имена, описания и очаквани входни данни, включително тези за инструмента add-task. Това може да се случи, преди да изпратите подкана.
Потребителски вход: Изпращате заявка до базираното на LLM приложение за бележки чрез вградения чатбот, например: „Създай задача в календара ми за преглед на новата ми чернова със среден приоритет.“
Обработка от модела: Хостът изпраща вашата заявка и съответните дефиниции на инструменти до LLM.
Избор на инструмент: LLM генерира структурирана заявка към инструмент, като посочва инструмента и входните му данни: add-task с title: Преглед на черновата и priority: Medium. Хостът проверява дали действието е разрешено и предава заявката на MCP клиента, който изпраща JSON-RPC съобщение.
Заявка: MCP клиентът изпраща заявка tools/call до своя MCP сървър.
Изпълнение на инструмента: MCP сървърът извиква API на приложението за управление на задачи, за да създаде нова задача със зададените заглавие и приоритет.
Връщане на резултата: Сървърът изпраща резултата обратно на MCP клиента, който го предава на хоста. Хостът го добавя към информацията, предоставена на LLM.
Генериране на отговор: LLM използва резултата, за да генерира отговор за потребителя, например: „Създадох задача за преглед на черновата със среден приоритет.“

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

Като предоставя на хост приложението една връзка за всеки доставчик на функционалност или вътрешен ресурс, MCP помага за решаването на проблема с претоварения входен контекст (изброяване на всички API) или ограничените API-базирани скриптове на приложенията.

Вместо това MCP сървърите могат да предоставят API (или по-точно функционалността, която извиква API) като част от своя списък с инструменти. Всеки път, когато доставчик актуализира приложението си и се появи нов API или документацията се промени, той просто актуализира MCP сървъра. Не са необходими промени в кода от страна на хост приложението.

Сигурността на MCP е обект на много дебати още от въвеждането му. Макар като цяло да се смята за безопасна технология, съществуват няколко риска за сигурността, много от които са по-изразени при сложни архитектурни имплементации.

MCP архитектурата има следните потенциални слабости:

Инжектиране на подкани: Потребител вмъква злонамерена подкана във външни данни, която AI моделът погрешно интерпретира като инструкция.
Достъп с прекомерни привилегии: MCP сървърите потенциално могат да предоставят голям брой инструменти на AI модел, което може да увеличи вероятността от проблеми със сигурността (радиуса на поражение).
Случайно изтичане на данни: Лошо конфигурираните имплементации могат да доведат до предаване на чувствителна информация, като API ключове или идентификационни данни за бази данни, на LLM.
Манипулиране на локалната система: Локалните MCP сървъри са също толкова уязвими към проблеми в локалната система, като злонамерени скриптове, колкото и всички други приложения, с допълнителния проблем, че могат да имат вредни последици надолу по веригата за агентните AI системи.

Нито един от тези проблеми не е непреодолим. Често утвърдените мерки са всичко необходимо, за да се гарантира безопасността на системата. Мерки като участие на човек в процеса, строг контрол върху чувствителните данни и защита от атаки срещу сървъра са обичайни практики.

MCP се утвърди като полезен и популярен отворен стандарт за разработчиците. Той преодолява много от проблемите на твърдо кодираните API в базирани на LLM приложения и значително намалява обема на програмиране за разработчиците.

Занапред основната хост-сървър архитектура на MCP почти сигурно ще остане същата. Бъдещите иновации ще се съсредоточат върху усъвършенствани агентни възможности в многостъпкови работни процеси.

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

Какво е MCP архитектура?

Компоненти на MCP архитектурата: хостове, клиенти и сървъри

Хост

Клиент

Сървър

Какво е слоят за данни в MCP архитектурата?

Какво е транспортният слой в MCP архитектурата?

Какво е многонаемателска MCP архитектура?

Диаграма на MCP архитектурата: преглед стъпка по стъпка

С какво MCP архитектурата се различава от традиционната API архитектура?

Сигурна ли е MCP архитектурата?

Какво предстои за MCP архитектурата?