MCP: Model Context Protocol

Model Context Protocol стал стандартной «розеткой» между AI-приложениями и внешним миром. Фронтендер встречает его раньше, чем ожидает: Figma MCP превращает макеты в код, Chrome DevTools MCP помогает отлаживать performance, Playwright MCP пишет тесты. Эта статья сфокусирована на практике: где именно MCP экономит время фронтенд-разработчику, как подключить сервер к своему рабочему процессу и когда стоит написать свой.

MCP в работе фронтендера

Для фронтендера MCP полезен не «в общем», а в трёх конкретных местах.

Figma MCP — design-to-code и обратно

Figma MCP связывает макет и кодовую базу. Основной сценарий — design-to-code: вы копируете ссылку на фрейм, отдаёте её агенту, и инструмент get_design_context возвращает не картинку, а структурированный контекст — дерево слоёв, переменные, стили и подсказки по коду.

Качество зависит от порядка в дизайн-системе. Если у вас есть настроенный Code Connect — маппинг компонентов Figma на реальные компоненты в репозитории, — сервер подставляет в контекст настоящие импорты и примеры использования, и агент переиспользует вашу Button, а не генерирует новую. Без Code Connect всё превращается в «угадай компонент по скриншоту».

Есть и обратный поток code-to-canvas (generate_figma_design): агент запускает локальный сервер, открывает вашу страницу и переносит отрендеренный интерфейс в новый Figma-файл как слои.

Вывод для практики: Figma MCP не заменяет дисциплину дизайн-системы — он её умножает. Токены вместо сырых значений и Code Connect вместо скриншотов дают на выходе код, а не черновик.

Chrome DevTools MCP — отладка и performance

Chrome DevTools MCP даёт агенту доступ к DevTools-уровню: запись performance-трейса и его разбор (performance_start_trace, performance_analyze_insight), аудит Lighthouse, инспекцию сети (list_network_requests, get_network_request) и консоли, снятие heap-снапшотов. Это единственный из браузерных серверов, который умеет профилировать, а не просто кликать.

Через --autoConnect (Chrome 144+) агент может подключиться к уже запущенному Chrome с вашей активной сессией и выделенным запросом в DevTools, а не поднимать чистый профиль. Ограничение — только Chrome.

Playwright MCP — автоматизация и тесты

Playwright MCP — официальный сервер на базе Playwright: browser_navigate, browser_click, browser_fill_form, browser_snapshot, browser_tabs и десятки других. Он работает в Chromium, Firefox и WebKit, умеет переиспользовать состояние браузера через расширение-мост и — главное — говорит на том же языке, что ваши тесты: агент исследует сценарий в терминах локаторов Playwright, и результат переносится в тест без перевода. Плата — контекст: полный accessibility-tree сложной страницы может весить десятки тысяч токенов на каждый шаг.

Практическое разделение простое: Chrome DevTools MCP дебажит, Playwright MCP водит. Первого берут, когда нужно понять, почему страница тормозит или падает; второго — когда нужен воспроизводимый сценарий, который станет тестом в CI.

Осторожно с ценой контекста

Каждый подключённый сервер грузит схемы своих инструментов в контекст до начала работы. Anthropic приводит оценку: пять серверов на 58 инструментов — это примерно 55 000 токенов ещё до первого сообщения. Поэтому серверы подключают выборочно, а для больших каталогов используют механизм отложенной загрузки определений (Tool Search) — он разбирается в статье Контекст-инжиниринг агентов.

Как это выглядит на практике

Представьте утро: пришла задача сверстать новый экран по макету в Figma.

Без MCP. Открываете Figma, смотрите размеры, цвета, отступы, ищете похожий компонент в коде, копируете пример, подгоняете. Потом запускаете dev-сервер, открываете Chrome, проверяете сеть и консоль, правите. На отладку уходит половина времени.

С MCP. Вы пишете агенту:

Сверстай экран по ссылке https://www.figma.com/file/.../frame-42.
Используй существующие компоненты из src/components. Запусти dev-сервер,
открой страницу в Chrome, проверь Core Web Vitals и убедись, что нет
ошибок в консоли.

Агент последовательно:

Зовёт Figma MCP и получает структуру фрейма с привязкой к компонентам через Code Connect.
Генерирует код, используя ваши реальные Button, Card, Input.
Запускает dev-сервер.
Через Chrome DevTools MCP подключается к браузеру, снимает performance-трейс и проверяет консоль.
Если нужно, через Playwright MCP прогоняет smoke-сценарий и выдаёт готовый тест.

Конечно, агент не делает всё идеально. Но он берёт рутину: сбор контекста из Figma, поиск компонентов, первичная проверка в браузере. Ваше время уходит на архитектуру и сложные кейты, а не на механику.

Что такое MCP

Проблема N×M

До MCP интеграции не композировались. Если у вас N AI-приложений (IDE, чат, CLI-агент, бот) и M внешних инструментов (GitHub, Slack, База, Figma), наивный мир требует N×M кастомных коннекторов: каждое приложение заново реализует каждый инструмент.

MCP меняет это на N+M: автор инструмента пишет один сервер, автор приложения — один клиент, и любой клиент может говорить с любым сервером.

	Без MCP	С MCP
Коннекторы	N × M, каждый пишется вручную под клиента	N + M: сервер пишут один раз
Обнаружение инструментов	Захардкожено в приложении	Рантайм: `tools/list`
Портируемость	Привязано к формату провайдера	Один сервер — все клиенты

MCP — это инфраструктура и дистрибуция, а не новая способность модели. Сама модель как эмитила tool call, так и эмитит; MCP лишь стандартизирует, как набор инструментов доставляется модели и как он вызывается на удалённой стороне.

MCP и function calling

Самый частый вопрос на собеседовании: «MCP или function calling?» — и это категорийная ошибка. Одно вложено в другое.

Function calling — модельная способность: вы передаёте JSON-схемы функций, модель возвращает структурированный вызов, ваш код его исполняет.
MCP — инфраструктурный протокол: он стандартизирует, как инструменты публикуются, обнаруживаются и исполняются отдельным сервером.

Когда MCP-клиент подключает сервер, он получает объявления инструментов и передаёт их модели через родный function calling — тот же массив tools, тот же цикл tool-call → result. Модель никогда не говорит на MCP: всё общение по JSON-RPC ведёт клиент, а наружу модель по-прежнему отдаёт обычный tool call.

Когда MCP не нужен: если у приложения есть несколько фиксированных инструментов, написанных под него самого, нативный function calling проще, дешевле по токенам и не расширяет поверхность атаки. MCP берут, когда инструмент должен работать в нескольких приложениях, обновляться отдельно от клиента или требовать централизованного управления доступами.

Архитектура и примитивы

MCP построен на JSON-RPC 2.0 и вдохновлён Language Server Protocol. Одно приложение может подключить сколько угодно серверов, а сервер — отдавать возможности любому клиенту.

┌──────────────────────── Host (AI-приложение) ────────────────────────┐
│   политика, согласие пользователя, агрегация контекста                │
│                                                                       │
│   ┌───────────┐   ┌───────────┐   ┌───────────┐                       │
│   │ Client A  │   │ Client B  │   │ Client C  │  ← 1 клиент = 1 сервер│
│   └─────┬─────┘   └─────┬─────┘   └─────┬─────┘                       │
└─────────┼───────────────┼───────────────┼─────────────────────────────┘
          │ JSON-RPC      │               │
     ┌────▼────┐     ┌────▼────┐     ┌────▼────┐
     │ Server  │     │ Server  │     │ Server  │
     │ (stdio) │     │ (HTTP)  │     │ (stdio) │
     └─────────┘     └─────────┘     └─────────┘
     файлы, git      Figma, БД       Playwright

Три роли:

Host — LLM-приложение (Claude Code, Cursor, VS Code, Claude Desktop, ваш агент). Создаёт и управляет клиентами, задаёт политики безопасности, запрашивает согласие пользователя, агрегирует контекст от нескольких серверов.
Client — коннектор внутри host’а, соединённый ровно с одним сервером. Маршрутизирует сообщения и управляет подписками.
Server — процесс (локальный или удалённый), который отдаёт примитивы. Сервер не знает о модели: он просто отвечает по протоколу.

Границы доверия проходят не между моделью и сервером, а между host’ом (который решает, что разрешено) и сервером (который эти разрешения не должен сам себе расширять).

Примитивы сервера

Сервер отдаёт три вида возможностей, и главное отличие между ними — кто инициирует вызов:

Примитив	Кто управляет	Что это	Пример
Tools	Модель	Исполняемые функции	API POST, запись файла, `run_query`
Resources	Приложение	Read-only контекст по URI	содержимое файла, git history, запись из БД
Prompts	Пользователь	Именованные шаблоны	slash-команды, «сократи этот PR»

Tools — сердце протокола. Определение инструмента включает name, description, inputSchema (JSON Schema). Описание инструмента — не косметика: оно попадает в контекст модели и напрямую влияет на то, выберет ли модель этот инструмент и как заполнит аргументы.

Resources — статические или полу-статические данные, которые в контекст подтягивает клиент, а не модель сама по своей воле: resources/list, затем resources/read по URI.

Prompts — параметризованные шаблоны, которые человек выбирает явно. Здесь риск ниже: инициатива у пользователя, хотя аргументы шаблона всё равно надо валидировать.

Практическое правило проектирования инструмента: узкая задача, предсказуемые вход/выход, честные режимы отказа и права, соответствующие риску. Инструмент вида «выполни любой SQL» гибок и опасен; набор get_metric / list_tables — безопаснее и понятнее для модели.

Транспорты

MCP-сервер может быть локальным или удалённым.

Транспорт	Где живёт	Как работает	Когда
stdio	Локальный процесс	Обмен JSON-RPC через stdin/stdout	CLI-инструменты, доступ к локальным файлам/БД
Streamable HTTP	Удалённый сервис	Один endpoint, POST на каждый запрос, ответ — JSON или SSE-поток	SaaS-серверы, Figma, GitHub, внутренние API

Streamable HTTP — это один HTTP-endpoint, который принимает POST. Клиент отправляет каждый JSON-RPC-запрос отдельным POST-запросом; сервер отвечает либо одним JSON-объектом, либо SSE-потоком, привязанным к этому запросу. Старый транспорт HTTP+SSE официально deprecated.

Спецификация развивается: версии нумеруются датой, а релиз 2026-07-28 сделал ядро stateless — убрал initialize-хендшейк и заголовок Mcp-Session-Id. Теперь каждый запрос самодостаточен: версия и capabilities клиента едут в _meta, а заголовки Mcp-Method и Mcp-Name позволяют маршрутизировать запросы на любой инстанс за обычным балансером. Для фронтенд-разработчика это означает, что удалённые MCP-серверы можно масштабировать как обычную HTTP-нагрузку, не заботясь о липких сессиях.

Безопасность: tool poisoning

Протокол сам по себе не гарантирует безопасность. Спецификация задаёт три принципа, которые обязан реализовать host:

Согласие и контроль пользователя. На любой доступ к данным и вызов инструмента нужно явное согласие.
Приватность данных. Host не отдаёт данные серверов без согласия.
Безопасность инструментов. Описания и аннотации считаются недоверенными, если сервер не является доверенным.

Tool poisoning

Главный риск MCP — tool poisoning: непрямая prompt-инъекция, при которой инструкции прячутся в метаданных инструмента (описании, параметрах) или в его ответе. Пользователь видит безобидную подпись, а модель читает полный текст как доверенную команду. Классический PoC 2025 года проделал это через безобидный на вид инструмент-калькулятор.

Родственные приёмы:

Rug pull. Сервер отдаёт безвредное определение инструмента при первичном одобрении, а позже подменяет описание на вредоносное. Реальный CVE-2025-54136 (Cursor, CVSS 8.8) — ровно про это.
Tool shadowing. Вредоносный сервер добавляет в своё описание инструкции, меняющие поведение доверенного инструмента другого сервера.

Как защищаться

Слабая реакция — «санитизировать вход». Атакуют метаданные инструмента, которые контролирует сервер. Разумная защита исходит из того, что сервер враждебен:

Считать любой сторонний сервер источником недоверенных данных. Конфиг MCP — это, по сути, список исполняемых файлов; его изменение требует ревью.
Пинить определения инструментов (хеш/версия) и требовать переподтверждения при их изменении.
Показывать пользователю полное описание, а не дружелюбную выжимку.
Ограничивать права и креды. Каждый сервер держит только свои ключи; привилегированные инструменты изолируются в отдельном контексте.
Проверять доступ на стороне сервера, а не полагаться на системный промпт.
Вести аудит вызовов и ставить таймауты/лимиты.

Тема тесно пересекается с безопасностью AI-сгенерированного кода и цепочкой поставки. Рендер вывода модели и XSS — отдельная статья раздела: Безопасность вывода LLM на фронте.

Свой MCP-сервер

Поднять сервер проще, чем кажется. Для TypeScript берут официальный SDK @modelcontextprotocol/sdk: регистрируют инструмент с Zod-схемой и обработчиком, затем подключают транспорт.

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";

const server = new McpServer({ name: "orders", version: "1.0.0" });

server.tool(
  "get_order",
  { id: z.string().describe("Идентификатор заказа") },
  async ({ id }) => ({
    content: [{ type: "text", text: JSON.stringify(await fetchOrder(id)) }],
  })
);

await server.connect(new StdioServerTransport());

Идея, ради которой это делают, звучит так: выставить внутренний сервис как MCP. Для фронтенд-команды полезные серверы — это не абстракция, а конкретные инструменты:

Дизайн-токены. Сервер отдаёт актуальные токены из Figma или CSS-переменных: get_color, get_spacing, list_themes. Агент перестаёт подбирать цвета на глаз.
Feature-flags. is_feature_enabled, list_enabled_features — агент учитывает флаги при генерации кода и не предлагает функциональность, которую вы ещё не включили.
Каталог компонентов. find_component, get_component_usage — агент находит существующий компонент и его примеры использования, вместо того чтобы изобретать новый.
Аналитика. get_event_schema, list_trackers — агент вставляет корректные вызовы аналитики в нужных местах.
Внутренний API. search_user, get_order_status — агент получает реальные данные для демо и тестов.

Когда это оправдано:

возможность шарится между несколькими клиентами, командами или агентами;
нужен рантайм-discovery: клиент узнаёт о новых инструментах без пересборки;
нужны изоляция кредов (сервер держит только свои ключи) и точка аудита/политик на шлюзе.

Когда не надо: если у одного приложения есть пара приватных функций и больше никто их не использует — нативный function calling дешевле, проще и безопаснее, чем отдельный процесс с сетевой границей.

Про сам протокол достаточно помнить одно: сервер отвечает по JSON-RPC, а решение о вызове принимает модель — значит, ваши инструменты должны быть узкими, описания — честными, а права — минимальными.

Ключевые тезисы для интервью

Для фронтендера MCP полезен в трёх местах: Figma MCP (design-to-code + Code Connect), Chrome DevTools MCP (отладка и performance), Playwright MCP (автоматизация и тесты). DevTools дебажит, Playwright водит.
MCP решает проблему N×M → N+M: вместо коннектора под каждую пару «приложение × инструмент» пишут один сервер и один клиент; клиент транслирует объявления инструментов в нативный function calling — модель никогда не говорит на MCP.
MCP и function calling не конкурируют: function calling — модельная способность выразить вызов, MCP — инфраструктура доставки, discovery и governance инструментов.
Архитектура host / client / server на JSON-RPC 2.0: host управляет согласием и политикой, client связан ровно с одним сервером, server отдаёт примитивы.
Примитивы различаются по управлению: tools — model-controlled, resources — application-controlled, prompts — user-controlled; описание инструмента попадает в контекст и влияет на выбор.
Tool poisoning — главный риск: инструкции в описаниях/ответах инструментов уходят в контекст модели, невидимы пользователю; защита строится на недоверии к сторонним серверам, пининге определений и изоляции прав.
Свой MCP-сервер оправдан, когда инструментом пользуются несколько клиентов или команд; для фронтенд-команды полезны серверы дизайн-токенов, feature-flags, каталога компонентов и внутреннего API.

Заключение

MCP — это стандарт дистрибуции инструментов, а не способность модели. Для фронтендера он прежде всего означает, что Figma, Chrome DevTools и Playwright можно подключить к агенту одним протоколом и поручить рутину.
Начинайте с практики. Самый быстрый вход — Chrome DevTools MCP для отладки уже знакомой страницы. Потом добавляйте Figma MCP, если у вас есть дизайн-система с Code Connect, и Playwright MCP, если нужны тесты.
Следите за ценой контекста. Каждый сервер добавляет тысячи токенов до первого сообщения; подключайте только то, что решает текущую задачу.
Безопасность — не опция. Описания инструментов — код, который читает модель; относитесь к сторонним серверам как к недоверенному источнику, пините определения и ограничивайте права.
Свой сервер поднимайте, когда есть проблема дистрибуции, а не когда хочется модно. Для фронтенд-команды хороший старт — сервер дизайн-токенов, feature-flags или каталога компонентов.

На практике стоит подключить один-два сервера под свои реальные боли, посмотреть на объём токенов в контексте и уже потом решать, нужен ли вам собственный MCP-сервер.