Кто я и где мы

О чём поговорим?

1. 01Агент и MCP за пять минут
2. 02Стартап против инфраструктуры
3. 03Deckhouse и первый MCP-сервер
4. 04spec-first и protoc-gen-mcp
5. 05deckhouse-harness изнутри
6. 06Сценарии и живое демо

О чём поговорим?

• 01Агент и MCP за пять минут
• 02Стартап против инфраструктуры
• 03Deckhouse и первый MCP-сервер
• 04spec-first и protoc-gen-mcp
• 05deckhouse-harness изнутри
• 06Сценарии и живое демо

LLM умна, но безрука

• Модель отлично рассуждает
• Но сама по себе ничего не делает в реальном мире
• → чтобы действовать, ей нужны руки

Анатомия агента

MCP = USB-C для интеграций

• Один протокол вместо зоопарка кастомных коннекторов
• Агент видит и вызывает внешние действия через один стандарт
• MCP-сервер = руки агента

Три примитива

Как агент выбирает tool

Два транспорта

один бинарь - оба транспорта: TRANSPORT=sse LISTEN_ADDR=:8080

Аннотации: контракт безопасности

Клиент читает аннотации и понимает, где нужен человек.

О чём поговорим?

• 01Агент и MCP за пять минут
• 02Стартап против инфраструктуры
• 03Deckhouse и первый MCP-сервер
• 04spec-first и protoc-gen-mcp
• 05deckhouse-harness изнутри
• 06Сценарии и живое демо

Задача

• Продукту нужна настоящая инфраструктура: Kubernetes, деплои, TLS
• В команде - только бэкенд-разработчики
• DevOps-инженера нет и не будет

Что нам реально нужно

1. Поднять и держать кластер
2. Добавлять ноды, когда не хватает ресурсов
3. Выпускать сервисы наружу: Ingress + TLS
4. Понимать, что сломалось, быстро
5. Обновлять платформу без страха

И всё это - без выделенной команды.

Экономика вопроса

Ставка

Не нанимаем DevOps.
Отдаём управление инфраструктурой агенту.

Попытка №1: готовый Kubernetes MCP

Agent<br>  │<br>  ▼<br>MCP (Kubernetes)   ← готовый сервер с kubectl-тулами<br>  │<br>  ▼<br>kube-apiserver

Почему не взлетело

• Сырой kubectl-уровень: агент тонет в низкоуровневых объектах
• Нет модели нашего домена: «добавь ноду» ≠ 20 kubectl-команд
• Опасные операции без ограничений и без аннотаций
• → нужен доменный MCP-сервер, а не обёртка над kubectl

О чём поговорим?

• 01Агент и MCP за пять минут
• 02Стартап против инфраструктуры
• 03Deckhouse и первый MCP-сервер
• 04spec-first и protoc-gen-mcp
• 05deckhouse-harness изнутри
• 06Сценарии и живое демо

Что такое Deckhouse

• Kubernetes-платформа: кластер + модули «из коробки»
• Мониторинг, ingress, cert-manager, автообновления - уже внутри
• Вся платформа управляется декларативно через CRD

CRD: декларативный интерфейс платформы

apiVersion: deckhouse.io/v1<br>kind: NodeGroup<br>metadata:<br>  name: worker<br>spec:<br>  nodeType: Static<br>  staticInstances:<br>    count: 3<br>    labelSelector:<br>      matchLabels:<br>        role: worker

Вердикт

Идея

Пишем свой MCP-сервер над Deckhouse:
доменные тулы вместо сырого kubectl.

Начали писать руками

• Каждый tool: схема + валидация + хендлер + описание
• Первые 5 тулов - нормально
• Дальше - копипаста и расхождение схем

Проблема масштаба

• Нужны десятки тулов: ноды, модули, релизы, конфиги, диагностика
• JSON Schema руками = ошибки в каждой второй
• Схема, код и описание живут отдельно и расходятся

Симптом

Диагноз

Проблема не в коде.
Проблема в том, что нет единого источника правды.

О чём поговорим?

• 01Агент и MCP за пять минут
• 02Стартап против инфраструктуры
• 03Deckhouse и первый MCP-сервер
• 04spec-first и protoc-gen-mcp
• 05deckhouse-harness изнутри
• 06Сценарии и живое демо

Нужен источник правды

• Одна спецификация → схема, код и описания генерируются
• Руками пишем только бизнес-логику хендлеров
• → подход называется spec-first

OpenAPI vs Protobuf

Решение

Берём proto как единственный источник правды
и пишем свой генератор: protoc-gen-mcp.

Идея protoc-gen-mcp

• proto-сервис → набор MCP-тулов
• rpc → tool, message → JSON Schema, комментарий → description
• Опции метода → аннотации безопасности

rpc + опции = tool с аннотациями

service DiagnosticsAPI {<br>  // Статус кластера: ноды, модули, алерты.<br>  rpc GetClusterStatus(GetClusterStatusRequest)<br>      returns (GetClusterStatusResponse) {<br>    option (mcp.options.v1.method) = {<br>      read_only_hint: true<br>    };<br>  }<br>}

Пайплайн: от proto до сервера

.proto (источник правды)<br>  │  easyp generate / buf generate<br>  ▼<br>protoc-gen-mcp<br>  ├─▶ JSON Schema для каждого tool<br>  ├─▶ интерфейсы хендлеров<br>  ├─▶ регистрация тулов + аннотации<br>  └─▶ валидация входа из constraints<br>  │<br>  ▼<br>ваш код: только бизнес-логика хендлеров

Constraints: валидация из спецификации

message AddWorkerNodeRequest {<br>  string name = 1 [(mcp.options.v1.field) = {<br>    string: { min_len: 1, max_len: 63,<br>              pattern: "^[a-z0-9-]+$" }<br>  }];<br>  int32 cpu = 2 [(mcp.options.v1.field) = {<br>    int32: { gte: 1, lte: 64 }<br>  }];<br>}

Почему это работает

• Схема и код не могут разойтись - они из одного файла
• Комментарий в proto = description для агента
• Новый tool = новый rpc + один хендлер
• Ревью спецификации вместо ревью бойлерплейта

Где болело: zero values

• В protojson «поле не передано» и «передан ноль» выглядят одинаково
• Агент пропускает поле → сервер видит 0 → логика ломается
• Решение: UNSET-sentinel в рантайме - явно различаем «нет значения» и «ноль»

Один proto - пять языков

Эволюция за полгода

Мета-уровень

Агент сам умеет пользоваться генератором:
агент пишет proto → генерирует себе руки

Руками - только бизнес-логика

// Сгенерировано protoc-gen-mcp. Не редактировать.<br>type DiagnosticsAPIToolHandler interface {<br>	GetClusterStatus(<br>		ctx context.Context,<br>		req *deckhousev1.GetClusterStatusRequest,<br>	) (*deckhousev1.GetClusterStatusResponse, error)<br><br>	ListUnhealthyPods(<br>		ctx context.Context,<br>		req *deckhousev1.ListUnhealthyPodsRequest,<br>	) (*deckhousev1.ListUnhealthyPodsResponse, error)<br>}

Генерация одной командой

generate:<br>  plugins:<br>    - name: go<br>      out: gen<br>    - name: mcp<br>      out: gen<br>      opts:<br>        lang: go

Сборка сервера

srv := mcpruntime.NewServer("deckhouse-harness")<br><br>deckhousev1.RegisterDiagnosticsAPITools(<br>	srv, diagnosticsHandler,<br>)<br>deckhousev1.RegisterNodesAPITools(<br>	srv, nodesHandler,<br>)<br><br>if transport == "sse" {<br>	return srv.ServeSSE(ctx, listenAddr)<br>}<br>return srv.ServeStdio(ctx)

О чём поговорим?

• 01Агент и MCP за пять минут
• 02Стартап против инфраструктуры
• 03Deckhouse и первый MCP-сервер
• 04spec-first и protoc-gen-mcp
• 05deckhouse-harness изнутри
• 06Сценарии и живое демо

43 тула, 6 доменов

Каждый домен = отдельный proto-сервис в proto/deckhouse/v1/

Тул ≠ один API-вызов

Один вызов агента = целый сценарий внутри хендлера

Один бинарь - два режима

# локально: stdio + kubeconfig разработчика<br>./deckhouse-harness<br><br># в кластере: Pod в d8-system, in-cluster auth<br>TRANSPORT=sse LISTEN_ADDR=:8080 ./deckhouse-harness

Границы доверия

• Аннотации: read-only тулы агент зовёт свободно
• destructive-тулы - только с подтверждением человека
• RBAC: ServiceAccount ограничен тем, что реально нужно
• даже сломавшийся агент не сделает больше, чем разрешено

Боевая история: одна буква

• Опечатка в GVR: resource в единственном числе
• 133 unit-теста с моками - все зелёные 🟢
• Поймали только интеграционные тесты на живом кластере
• → моки врут, кластер - нет

Как тестировать руки агента

Интеграционные тесты гоняют реальные MCP-вызовы через оба транспорта.

О чём поговорим?

• 01Агент и MCP за пять минут
• 02Стартап против инфраструктуры
• 03Deckhouse и первый MCP-сервер
• 04spec-first и protoc-gen-mcp
• 05deckhouse-harness изнутри
• 06Сценарии и живое демо

Сценарий A: диагностика

Сценарий B: новая нода

Сценарий C: HTTPS за один вызов

Сценарий D: разбор инцидента

Вся цепочка - read-only тулы: агент расследует без риска, решение принимает человек.

Что мы только что видели

Шесть тезисов

1. Агенту нужны доменные руки, а не сырой kubectl
2. Руки руками не масштабируются - нужен источник правды
3. proto + protoc-gen-mcp: схема, код и описания из одного файла
4. Агент ужасно проектирует, но неплохо кодит
5. Один proto - пять языков MCP-серверов
6. Доверие агенту = аннотации + RBAC + интеграционные тесты

Когда это вам подойдёт

Планы

Итог в цифрах

43 тула · 6 proto-сервисов
133+58 тестов · 5 языков
0 нанятых DevOps