WB прикрыл лавочку с «публичными» данными. Больше никаких остатков, цен и рекламных ставок для сторонних аналитик. Всё, что парсилось годами и кормило десятки тысяч селлеров лайфхаками — превратилось в труху.
Что это значит: - Аналитические сервисы — парализованы - Те, кто строил бизнес на чужих данных, теперь либо переписывают продукт, либо закрывают офис - Селлеры — остаются один на один с личным кабинетом и API по токену - Хотите прогнозов и репрайсинга? Учитесь работать со своими данными, а не подглядывать у соседа. - Рынок — ждёт большая чистка - Выживут только те инструменты, что помогают реально автоматизировать процессы на основе внутренних цифр, а не «угадай цену конкурента»
Wildberries чётко дал понять: «мы зарабатываем на нормальных поставщиках, а не на охотниках за хитростями»
По итогу — больно будет аналитическим платформам, а для селлеров это сигнал взрослеть: прокачивать ассортимент, сервис и клиентский опыт
Яндекс снова на обложке, хотя теперь под именем Nebius. После сделки с Microsoft акции в США улетели на +71%. Формально — всё красиво: дата-центр в Нью-Джерси, контракт на $17+ млрд до 2031 года. Но за кулисами это выглядит чуть иначе.
Главная проблема индустрии — NVIDIA ограничивает квоты на свои чипы. Это значит, что даже гиганты вроде Microsoft не могут прийти и сказать: «Дайте нам вагон H100, мы оплатим картой». Карточек тупо нет столько, сколько всем нужно. Поэтому Microsoft вынужден искать партнёров, у которых есть доступ к чипам через свои каналы.
Появляется Nebius. У компании свой лимит на железо, свои отношения с NVIDIA — и теперь кусок этого лимита фактически «арендован» Microsoft. То есть вместо того, чтобы напрямую выбивать квоты, корпорация берёт вычислительные мощности у бывшей «Яндекс N.V.».
Хочу рассказать про Diffusion модели и одну проблему, которую решили в статье "Fast and Fluent Diffusion Language Models via Convolutional Decoding and Rejective Fine-tuning"
Представьте: вы пишете письмо в саппорт. Большое, с болью, как положено. А потом система берёт и начинает стирать из него слова. Сначала одно-два, потом половину. В итоге доходит до состояния «*** не работает *** вчера *** клиенты». Это называется forward-процесс. То есть сначала текст намеренно превращают в кашу.
Дальше reverse-процесс. Модель берёт этот обрубок и пытается догадаться, что же там было. Сначала простые слова (имена, даты). Потом технические термины. Потом связки. И вот у вас снова появляется более-менее внятное письмо. Это обучение через боль: чтобы в будущем модель могла достраивать даже то, чего не слышала.
Теперь внимание. В обычных генеративках текст растёт пословно, как будто вы диктуете. В диффузии всё наоборот: модель сразу пуляет целое «окно» текста, пытаясь угадать кучу слов одновременно. Звучит круто? Ага, только дальше начинается Long Decoding Window. Чем дальше от начала, тем больше мозг модели закипает. Итог: повторы, бессмысленные вставки, рандомный шум. Письмо начинается адекватно, а заканчивается как будто писал уставший стажёр.
Учёные посмотрели на этот и сказали: ладно, давайте хотя бы починим. Придумали Convolutional Decoding — это как если бы у стажёра попросили сначала сосредоточиться на ближних словах, а дальние воспринимать с осторожностью. Добавили Rejective Fine-Tuning — модель теперь штрафуют за «the the the» и «: : :». И добили EOS-fill: как только модель ставит точку, всё дальше просто забивается точками, и никто не позорится.
Рабочее решение: — Convolutional Decoding — как если бы стажёру сказали: «сначала смотри на ближние слова, а дальние фильтруй». — Rejective Fine-Tuning — за повторы и мусор прилетает штраф, и модель учится так не делать. — EOS-fill — как только модель ставит точку, дальше всё затирается точками, и никто не позорится.
Результат: та же диффузия, но быстрее, чище и без проблем на длинных текстах. Выглядит как будто саппорт наконец-то перестал косплеить генератор случайных слов и начал отвечать по делу.
Разбираю статью про обучение с подкрплением для самых маленьких и генерацию ответов
Все мы знаем, что большие модели любят учиться на готовых ответах. Но, угадай что? Готовых ответов у нас нет. Они либо дорогие, либо спорные, либо вообще непонятно какие. Представь, что у тебя есть только ты сам, твои черновики и пара свободных вечеров. Ну что, будем учиться на своих же косяках?
Вот для этого придумали Compute as Teacher (CaT). Работает оно так:
Модель честно пишет сразу несколько версий ответа. Каждая по-своему кривая, но иногда попадаются удачные куски.
Другая копия этой же модели собирает из них «лучший хит» — вроде плейлиста «самое ок» из твоих старых песен.
Потом мы сравниваем все черновики с этим «финальным шедевром» и решаем: «ага, вот это было ближе, а это лучше забыть как страшный сон».
Модель сама делает выводы и в следующий раз уже тупит чуть меньше.
В итоге получается странная штука: модель учится без учителя, проверяя сама себя. Как если бы школьник писал 5 вариантов решения задачи, потом сам делал «сборку Франкенштейна» из них, и именно её принимал за эталон. А дальше наказывает себя за плохие черновики и хвалит за удачные.
И что самое весёлое — это реально работает. Без людей, без правильных ответов, без пафоса. Просто куча вычислений, которые модель тратит на то, чтобы спорить сама с собой и становиться чуть умнее.
Если коротко: CaT — это как спорить с самим собой в душе, только полезно
Ссылка на статью у меня в блоге, потому что у меня карма маленькая и тут я не могу всё опубликовать
На форуме OpenAI Developer Community прошла забавная дискуссия про то, как использовать ChatGPT для написания целых книг.
Один из участников поделился схемой: чтобы текст выглядел связным, модель нужно кормить сразу всем — и планом всей книги, и структурой текущей главы, и кратким пересказом того, что уже написано, и даже сотней последних предложений, чтобы она могла продолжать без повторов. Рабочая идея, но доверять ChatGPT автор советует не больше, чем на тысячу слов: дальше качество неизбежно падает. Вывод получился трезвый — нейросеть не писатель, а помощник-черновик, которому можно поручить наброски, а потом придётся редактировать самому.
В обсуждении нашлось место и более экзотическим кейсам. Кто-то мечтает о веб-приложении для массового выпуска книг, другой собирается оживить собственный 40-летний нонфикшен, третий хочет перегнать тысячи книг в одну «сжатую» на тему эмоционального интеллекта. Сообщество настроено скептически, но советует попробовать: писать по главам, смотреть на результат и «очеловечивать» текст. В сухом остатке — ChatGPT пока что не литературный гений, но инструмент для авторов, которые готовы взять на себя роль строгого редактора.
Email и бухгалтерия: почему заголовки писем всё ещё угрожают деньгам компаний
Недавно я писал в одной из новостей про новый стандарт электронной почты — RFC 9788. Тогда это выглядело как чисто техническое обновление: поправили старый костыль, добавили пару параметров, придумали новые заголовки. Но если посмотреть на это глазами бизнеса, особенно глазами топ-менеджмента и бухгалтерии, картина оказывается совсем другой.
Электронная почта — это не только переписка с коллегами или рассылка клиентам. Это канал, через который каждый день проходят платёжки, инвойсы, запросы на переводы. И именно эта часть коммуникаций десятилетиями оставалась в зоне риска, потому что заголовки писем (From, Subject, To) никак не защищались. Мы могли шифровать тело письма, подписывать вложения, использовать все возможные фильтры, но если злоумышленнику хотелось заменить тему на «Срочный перевод контрагенту», он мог это сделать.
В результате бухгалтер получал письмо, где всё выглядело честно: защищённый текст, привычный формат счёта, даже подпись была на месте. А заголовки — самое видимое и доверенное место письма — могли быть переписаны. Именно на этом десятилетиями держались самые простые и самые успешные схемы email-фишинга.
И вот только в 2025 году IETF принял новый стандарт — RFC 9788. Он наконец-то говорит очевидную вещь: защищать нужно не только тело письма, но и заголовки. Теперь все поля копируются внутрь зашифрованной части, наружу выходит только технический минимум, а тема письма может заменяться на […]. Если кто-то попробует подделать заголовок, клиент сразу покажет рассинхрон.
Для разработчиков это очередная спецификация, набор правил и тестов. А для бизнеса это история про деньги и риски. Потому что каждый случай, когда бухгалтер ошибся и отправил платёж по фейковому письму, — это прямой убыток. Каждый подобный инцидент — это ещё и риск для репутации: в новостях упоминают не мошенников, а именно ту компанию, которая «повелась».
Да, внедрение будет постепенным: сначала open source-клиенты и энтузиасты, потом корпоративные почтовики, потом массовый рынок. Но уже сейчас очевидно, что компании, которые раньше внедрят RFC 9788, снизят риски быстрее. Это история не про «технологическую моду», а про то, сколько денег вы теряете или экономите.
Я уверен, что лет через пять защищённые заголовки будут восприниматься так же естественно, как сегодня HTTPS на сайтах. И точно так же, как сейчас мы удивляемся сайтам без https, пользователи будут удивляться письмам, где можно переписать тему или отправителя. Вопрос только в том, вы хотите оказаться в числе тех, кто внедрил это вовремя, или в числе тех, чью бухгалтерию упомянут в очередной криминальной хронике.
RFC 9828: стандарт, который, странным образом, опоздал лет на двадцать
JPEG 2000, появившийся ещё в начале нулевых, давно используется в задачах, где требуется высокое качество изображения, а RTP как транспорт для данных реального времени уже более двадцати лет обеспечивает надёжность. Однако, и это удивительно, всё это время отсутствовал формализованный стандарт, позволяющий передавать JPEG 2000 с минимальной задержкой, по кускам кадра, не дожидаясь его полной готовности, — и лишь в 2025 году он был наконец принят. Можно только гадать, почему в мире, где запускают ракеты в космос по подписке, инженеры продолжали смиренно ждать, пока кадр целиком упадёт в буфер.
Теперь же, с появлением RFC 9828, ситуация меняется: простое на первый взгляд решение — передавать кадр частями, а не целиком, — становится официальной нормой. Как только кодер начинает производить данные, пакеты уже могут быть отправлены в сеть, а приёмник, не дожидаясь окончания всего кадра, начинает сборку изображения. И именно это означает, что впервые JPEG 2000 становится пригодным для таких сценариев, где маркетинговый термин «low latency» оборачивается критическим требованием: телевещание в прямом эфире, дистанционная хирургия или работа со сверхкачественным изображением в реальном времени.
Вместо прежнего порядка «сначала кадр, затем поток» появляется обратный — «сначала поток, затем кадр». Благодаря этому сеть получает ту самую гибкость, о которой раньше говорили как о недостижимой: лишние уровни разрешения и качества можно отбрасывать на лету, даже не вскрывая содержимое. Приёмник, в свою очередь, обретает resync-точки, благодаря которым потеря пары пакетов больше не превращается в катастрофу, а разработчики, наконец, могут избавиться от бесконечных костылей, изобретённых в обход RFC 5371.
Выгоды для бизнеса очевидны, хотя каждый сектор формулирует их по-своему. В телевидении по IP режиссёр теперь видит кадр практически сразу, а не спустя полсекунды, и значит — работа в реальном времени перестаёт быть фикцией. В медицине появляется возможность стримить эндоскопию или МРТ с качеством вплоть до lossless и при этом не терять драгоценные секунды, от которых зависит исход операции. Кинопроизводство перестаёт таскать гигабайты по дискам, потому что мастер-кадры наконец-то могут пересылаться по сети. Даже государственные сервисы, включая суды и видеоконференции, приобретают шанс выглядеть не как мем из 2008 года, а как инструмент XXI века.
Да, пока это лишь бумага. Но, как обычно бывает: сначала RFC, затем — первые SDK и FPGA-решения, а чуть позже — перепакованные в отраслевые документы SMPTE и ITU стандарты. В горизонте двух-трёх лет мы увидим первые реальные внедрения в телевидении и медицине, в горизонте пяти — широкое распространение. А дальше, возможно, даже lossless-видеозвонки без лагов перестанут казаться фантастикой.
RFC 9828 — это не просто ещё один формат. Это признание индустрии в том, что ждать конца кадра всё это время было, мягко говоря, глупо.
Ну, что, господа, мир первернулся. Точнее сделал кувырок назад, звонко взвизгнул и побежал
Рынок развернулся на все 185.5 процентов и теперь происходят чудеса
C++-разраб с 15 годами опыта ищет на фрилансе человека, который найдёт ему работу. И вот что чудесно. То ли человек такой смышлённый, то ли я не знаю, но рядом, прямо тут лежат заказы на работу
Но сам факт наличия такого объявления говорит о капитальных сдвигах в IT-секторе экономики
Авторы из AI Institute, University of Montreal, Princeton University. Статья внушает доверие. Она также подтверждается моими собственными наблюдениями
Ребята говорят о экономии токенов на модельках, 46% меньше потребление ресурса + как следствие ускорение
Суть в том, что модели много рассуждают об известных фактах. Например, если модель попросить решить уравнение с геометрической прогрессией. Она сначала его выведет, а потом будет решать. И так шагов может быть много. У больших моделей есть привычка «думать вслух». Они, когда решают задачу, раскладывают всё по шагам — иногда очень длинно. Это классно для качества, но плохо для скорости и денег: чем больше токенов, тем дороже и медленнее
Пример на прогрессии
Ты просишь модель: «реши уравнение с геометрической прогрессией»
Что она делает?
Сначала начинает выводить саму формулу суммы прогрессии: пишет длинное рассуждение, как она получается.
Потом подставляет числа.
Потом делает вычисления.
И только в конце даёт ответ.
Каждый раз она повторяет эту историю, как будто «заново изобретает велосипед».
Что предлагают авторы статьи
Ребята говорят: зачем каждый раз заново выводить одно и то же? Давайте выделим такие повторяющиеся шаги в маленькие «карточки-подсказки» (они называют их behaviors).
Например, поведение: «Сумма первых n членов геометрической прогрессии = (a₁(1–qⁿ)) / (1–q)».
Теперь, когда модель решает задачу, мы ей сразу даём эту карточку. Она не тратит сотни слов на то, чтобы вывести формулу, а сразу использует её.
Почему это полезно
Экономия ресурсов: в экспериментах до 46% меньше токенов.
Ускорение: модель тратит меньше времени на текст.
Качество не падает, а иногда даже лучше — потому что меньше места для ошибок.
Итог
Классика: модель сама думает длинно, это дорого и долго.
Новый подход: мы даём ей готовые «кирпичики рассуждений» (behaviors), она использует их и отвечает быстрее.
В общем виде: решение = текст задачи + набор подсказок.
Тут можно формулы привести со всякими условными вероятностями. Душнить не буду. И так надо форточку открывать
RCS (Rich Communication Services) — это эволюция SMS/MMS, протокол, который мобильные операторы и Google продвигают как «мессенджер по умолчанию». Если SMS = plain text, то RCS = полноценные интерактивные сообщения с кнопками, каруселями, картинками, видео, QR-кодами и встроенной аналитикой.
Ключевые моменты
Протокол: работает поверх IP, а не через старую SMS-сеть, но доставляется в «стоковое» приложение сообщений (Google Messages, Samsung Messages).
API: доступ через Google Jibe Hub (фактически, центр маршрутизации), плюс нужно согласование с операторами. Прямо в код «в лоб» не залезешь — всё через провайдеров/агрегаторов.
Безопасность и доверие: каждая компания-отправитель проходит верификацию бренда, чтобы на экране у пользователя сообщения выглядели не как «спам», а с логотипом и цветами бренда.
UX: разработчик не отправляет просто текст, а собирает карточку или интерактив через шаблон/SDK → пользователю приходит сообщение, похожее на push или мини-приложение внутри SMS.
То есть RCS = «SMS на стероидах», но с кучей бизнес- и бюрократических ограничений. Главная боль — доступ к API и вся регуляторка, поэтому на рынок вышли «коробочные» сервисы (как Smobi), которые берут эти сложности на себя
Из сегодняшнего. Давно уже напрашивается MCP registry. Появился MCP реджистри. Не знаю, насколько аудитория погружена, поэтому если нет, то я подробнее распишу
Model Context Protocol (MCP) — это не классическое API, а новый слой взаимодействия между LLM и источниками данных: вместо того чтобы самому писать запросы, интеграции и «велосипеды», бизнес просто подключает MCP-серверы, которые находятся у провайдеров данных. Провайдер отвечает за подготовку промптов, функций, агрегацию источников и поддержку версий, а компания получает централизованный доступ к данным и готовым описаниям. Важно: MCP разводит зоны ответственности — финансы за работу LLM остаются у вас, а ответственность за качество данных и промптов несёт провайдер; таким образом, вы оптимизируете бюджеты, снижаете риски и можете гибко строить оркестрацию (через LangChain или свои пайплайны) без затрат на «ручные» интеграции с контролем версий отпровайдера
Раньше каждая команда или компания искала MCP-сервера вручную, через частные списки или разрозненные каталоги, что замедляло внедрение и поддержку клиентов. Теперь MCP Registry выступает единым «источником правды», где можно быстро находить, подключать и проверять сервера
Думаю, что ближайший год-два мы будем наблюдать, как наровне с публичными АПИ, будут появляться публичные MCP для интеграций. Что уж там, они есть уже у 1С даже, хотя там нюансы, конечно
MCP архитектура как развитие ручного подхода в LLM
Когда вы открываете ChatGPT и вставляете туда кучу текста — что реально происходит? Всё складывается в один длинный «бутерброд»: данные, инструкции, системный промпт, даже куски схемы в Markdown. Никакого порядка. Это как если бы у вас в кодовой базе был один файл main.py, где и роуты, и бизнес-логика, и SQL-запросы.
Я хочу описать идею MCP кратко, поскольку в самой доке она не описана. А может быть даже и не закладывалась туда. Но очень похоже, что такая архитектура хорошо работает исходя из более фундаментальных принципов, чем просто разделение
Как это выглядит у ChatGPT
На схеме выше видно:
Есть Line Edit — пользователь копипастит сырые данные.
Есть Плагин — иногда он что-то подмешивает.
Всё это сливается в один большой Склеенный промпт, который уходит в LLM.
Мешанина как она есть
Как это делает MCP?
MCP приходит и говорит: «ребята, давайте хоть модули разнесём».
System Prompt — отдельная часть, где живёт логика «как правильно жить» для модели.
Instruction Layer — патчи и локальные корректировки.
Schema Registry — отдельный каталог, который описывает структуру данных (таблицы, поля, форматы).
Data Adapter — слой, который достаёт данные у провайдера строго по схеме.
Всё это связывает MCP хост, который собирает финальный запрос к LLM, который зачастую представляет собой Lang Chain
Итог: модель получает запрос не как «мусорный мешок», а как структурированный pipeline.
Почему это важно
Прозрачность. Можно отследить, какая часть отвечает за что.
Контроль. Можно менять системный промпт без страха поломать данные.
Расширяемость. Хочешь новый источник данных? Добавь адаптер, а не переписывай всё.
Предсказуемость. Поведение модели становится ближе к детерминированному.
Простая метафора
ChatGPT — это когда у вас «final_final_v3.docx» и все правят его параллельно.
MCP — это когда у вас git с ветками, пайплайнами и CI с CQRS архитектурой (не шутка), читай выше
Зачем работать напрямую с клиентом, когда можно просто выкинуть запрос на MCP и дать нейросети подумать? 😎
Расскажу кейс Vivo Chat. Проверка статуса заказов (замените на вашу сущность). Давайте по порядку
Клиент идёт к хосту, чтобы получить доступ к MCP
Итак, наш клиент — это тот, кто первым инициирует запрос. Всё начинается с того, что клиент заходит в свою систему, которая подключена к MCP-серверу через хост. Хост выполняет функцию посредника, направляя запросы и получая ответы от разных компонентов системы.
Клиент: «Привет, хост, мне нужно проверить заказ, и я хочу понять, что из инструментария MCP мне пригодится. Покажи мне, пожалуйста, список доступных инструментов и подсказок, чтобы я мог выбрать что-то нужное для этого запроса.» Хост (перехватывает запрос и направляет его к серверу MCP): «Окей, сейчас все передам.»
Хост запрашивает у MCP список инструментов (Tools) и подсказок (Prompts)
Хост теперь идёт к MCP-серверу. Этот сервер знает всё, что связано с доступом к данным и обработкой запросов. В MCP сервере хранятся все инструменты (tools) и подсказки (prompts) для выполнения нужных действий.
Хост: «MCP, подкинь мне список доступных tools и prompts для запроса клиента.» MCP-сервер: «Вот, держи, вот все инструменты и подсказки, которые у нас есть. Для каждого метода я также подготовил параметры, которые можно подставить.»
LLM, любимая нейросеть, выбирает метод из списка
Теперь, когда хост получил список инструментов и подсказок, он передает всё это в LLM (нейросеть), которая и будет решать, какой метод нужно использовать для конкретного запроса.
Хост: «LLM, тебе пришёл запрос от клиента. Вот список инструментов и промптов. Тебе нужно выбрать подходящий метод для выполнения запроса и подготовить все нужные параметры для этого метода.» LLM: «Хорошо, я выбираю метод X из списка инструментов, и вот какие параметры мне нужны для этого метода. Я знаю, что нужно сделать, и использую соответствующие промпты, чтобы точно понять, что клиент хочет.»
LLM передает параметры и вызывает метод на MCP
Теперь, когда LLM выбрала нужный метод и подготовила параметры, она отправляет всё это хосту, который, в свою очередь, передает запрос обратно в MCP-сервер для выполнения.
LLM: «Вот всё, что мне нужно: метод X и параметры для выполнения. Передавай это на MCP.» Хост: «Принято, иду к MCP.»
Хост направляется к MCP-серверу и передает запрос на выполнение метода.
MCP выполняет метод и возвращает результат
MCP-сервер теперь, получив все необходимые данные, выполняет метод и обрабатывает запрос. Всё, что нужно, уже у него под рукой: инструменты, параметры, контекст. Вся обработка происходит внутри MCP, и сервер возвращает результат хосту.
MCP-сервер: «Я выполнил метод X с этими параметрами. Вот результат: (ответ).»
Ответ от LLM клиенту
Теперь, когда MCP выполнил метод, хост получает ответ и передает его обратно в LLM, которая уже анализирует результат, добавляет необходимые детали (например, форматирует или уточняет ответ) и отдает всё клиенту.
Хост: «Вот ответ от MCP через LLM: (ответ). Всё готово!» LLM: «Отлично, теперь я передаю результат обратно клиенту.» Клиент: «Вау, всё так быстро! Спасибо, LLM!»
Итог
На мой взгляд в бизнес-приложениях — это самый частый кейс, а всё остальное, связанное с обновлениями статусами заказов, удалениями данных будет упираться в безопасность и комплаенс
Я уже писал, из чего состоит протокол, как выглядят сервер и клиент, и зачем вообще всё это проксирование. Теперь — шаг вперёд: как вся эта архитектура живёт в реальных приложениях.
Если смотреть на схемы выше, то картина получается парадоксальная. Уровень связности высокий: запросы к LLM проксируются через хост, а MCP-сервера сидят как отдельные острова, каждый тянет свои данные — базы, файлы, API. На первый взгляд хочется спросить: «зачем такие сложности?». Ответ простой — тарификация и контроль. Если бы сервер напрямую ходил к LLM, владелец MCP оказывался бы заложником чужой экономики. А так запрос идёт через клиента/хост, и именно пользователь контролирует, когда и какой токен уходит в модель.
Важно понимать: MCP-сервер всегда на стороне провайдера данных. Это он готовит промпты, пишет функции, агрегирует источники. Ваша задача — не изобретать велосипеды, а собрать этих провайдеров, подключить через MCP и дальше использовать уже в своих оркестраторах (хоть LangChain, хоть самописные пайплайны).
Почему MCP имеет значение? Всё зависит от того, где вы стоите: – Разработчику MCP сокращает время интеграции и даёт готовый слой абстракций. – ИИ-приложениям MCP открывает экосистему источников и тулзов. – Пользователю MCP гарантирует, что его данные не уходят вслепую, а действия согласованы.
В сухом остатке: MCP — это не про «ещё один протокол», а про баланс удобства и контроля. Пример банальный, но показательный: пользователь хочет слетать в Барселону. Серверы MCP подтянули календарь, историю поездок, поиск рейсов и отелей. Агент сложил всё в кучу и забронировал отпуск за минуты. Задача, которая вручную заняла бы часы.
В следующей части разберём, какие паттерны интеграции MCP-серверов с LLM-оркестраторами реально просто работают
В прошлой заметке я писал про сервер и клиент, а теперь хочу копнуть глубже и пройтись по составу протокола. Это будет чуть упрощённая версия, чтобы не утонуть в спеке, но картинка станет понятнее.
На самом дне MCP — транспорт. Тут нет никакой магии: JSONRPC. Его работа — просто донести пакет от клиента до сервера и обратно. Запросы, ответы, нотификации, ошибки — всё аккуратно упаковано, но без бизнес-смысла.
Дальше идут данные. Со стороны сервера это Resources, Prompts, Tools. Resources управляют файлами, базой, API-ответами и прочим контекстом, который нужен ИИ-приложениям. Внутри этого — Content: текст, картинки, аудио, бинарь, блоки. Prompts описывают доступные подсказки и параметры. Tools — это исполняемые функции, которыми сервер делится с клиентом, от файловых операций до API вызовов.
Со стороны клиента данные другие. Sampling.Complete позволяет серверу дёрнуть LLM клиента без встроенного SDK. Elicit даёт возможность уточнить что-то у пользователя: параметры, подтверждения, ввод. Logging отправляет обратно логи и диагностику.
Есть и служебный слой: Initialize для рукопожатия, Capabilities для описания возможностей сторон, плюс сервисные штуки вроде уведомлений о прогрессе, подписок/отписок и отмен операций.
В итоге MCP — это не просто «реестр» инструментов, а полноценный протокольный шлюз. Сервер экспонирует ресурсы и инструменты, клиент решает, что из этого реально использовать. Баланс тот же: удобство для разработчиков серверов и полный контроль у пользователя.
В следующей заметке можно будет разобрать, как все эти части складываются в реальную работу: от того, как сервер отдаёт ресурсы, до того, как клиент подтверждает вызовы LLM.
Ну а чтобы вам не было скучно, я приложу сравнение протоколов, дабы можно было понять роль MCP относительно других
Хайп вокруг Model Context Protocol сейчас только набирает обороты. Все обсуждают, но толком мало кто понимает, как это работает под капотом. Я хочу поделиться тем, что сам знаю и использую, и начать серию заметок, где разберу протокол по слоям: от сервера до клиента. Без академического занудства, но с технической точностью.
Начнём с сервера. Это не просто API с ручками и базой. Это инфраструктура, которая хранит версии контрактов и управляет доступом к провайдерам через CQRS-подход. Только это не «чистый» CQRS, а своя интерпретация. У нас есть три ключевых блока: Tools — всё, что записывает (файлы, API вызовы, база), Resources — всё, что читается (ответы из API, файлы, БД), и Prompts — шаблоны и подсказки для взаимодействия. Вместе это даёт централизованный контроль и прозрачное управление контрактами.
Клиент, в отличие от классического сетевого «тупого» потребителя, выступает протокольным посредником. Он решает, что серверу можно, а что нельзя. Через Sampling клиент подтверждает вызовы к LLM, через Roots задаёт границы доступа к файловой системе, а через Elicitation уточняет недостающие данные у пользователя. Сервер может многое, но последнее слово всегда остаётся за клиентом.
В итоге MCP выглядит не как очередная модная аббревиатура, а как архитектурный способ держать баланс: серверу — удобство, пользователю — контроль. В следующей заметке покажу больше деталей клиентской стороны и зачем весь этот «слоёный пирог» вообще нужен.
