TL;DR. Live Direct Marketing (LDM) — B2B email-платформа с собственным MCP-сервером. Веб-интерфейс и MCP экспонируют один и тот же /api/* через HybridAuthGuard, поэтому при подключении к голосовому ассистенту через MCP агент получает ровно ту же поверхность, что и пользователь дашборда. Без дублирования контроллеров, без отдельного agent API.

Опробовали в полевых условиях на VODEXPO 2026: голосовая команда → рассылка по сегменту базы → пофайловая верификация доставки в инбокс. Ниже — архитектура, фрагменты кода, и где это всё реально ломается.

Контекст

LDM — мульти-тенантная платформа для B2B коммуникации: CRM (companies/contacts/leads), сегменты, креативы, рассылки, диалоги вход/выход, suppression/stop-lists, антиспам-маркинг, deliverability-чекер. Стек: NestJS + Prisma + PostgreSQL + BullMQ + Redis, фронт на React + Turborepo. Tenant-изоляция через отдельную БД на пользователя.

Главная особенность — пофайловая верификация попадания исходящих писем в инбокс через сеть seed-mailboxes.

Архитектурное решение: UI = MCP

Когда стало понятно, что MCP станет дефолт-стандартом для агентного доступа к SaaS, стандартный выбор был: писать отдельный agent-API mirror поверх существующего веб-API, или сделать единую поверхность. Выбрали второе.

Все эндпоинты живут под /api/*. Перед ними HybridAuthGuard, который умеет резолвить либо сессионный cookie (UI), либо Bearer-ключ формата ldm_pk_* (MCP/voice/external agent). Дальше — один контроллер, один scope-чек, одна бизнес-логика.

typescript

// упрощённо
@Injectable()
export class HybridAuthGuard implements CanActivate {
  async canActivate(ctx: ExecutionContext): Promise<boolean> {
    const req = ctx.switchToHttp().getRequest();

    // 1. Bearer (agent / MCP / voice skill)
    const m = req.headers.authorization?.match(/^Bearer (ldm_pk_\w+)$/);
    if (m) {
      const key = await this.apiKeys.verifyHash(m[1]);
      if (!key) throw new UnauthorizedException();
      req.user = key.user;
      req.scopes = key.scopes; // gated по grant
      return this.checkScopeFor(req);
    }

    // 2. Session cookie (web UI)
    const session = await this.sessions.fromCookie(req);
    if (!session) throw new UnauthorizedException();
    req.user = session.user;
    req.scopes = ['*']; // UI = full scope
    return true;
  }
}

Каждая capability описана в /.well-known/agent-card.json (A2A discovery) со своим scope-ом: email:send, crm:read, dialogs:write, mailing:write, и так далее. Bearer-ключ выпускается с явным набором scope-ов — голосовому навыку можно выдать ограниченный ключ, который умеет читать диалоги и слать письма из конкретного аккаунта, но не имеет доступа к exports, billing, suppression management.

MCP-сервер

Опубликован как npm-пакет ldm-crm-mcp. Под капотом тонкая обёртка над /api/*: берёт LDM_API_KEY из env, проксирует MCP-tool вызовы в HTTP. ~30 инструментов на частые операции, ~120 эндпоинтов всего доступно через generic invocation.

Конфиг Claude Desktop / Cursor:

json

{
  "mcpServers": {
    "ldm-crm": {
      "command": "npx",
      "args": ["-y", "ldm-crm-mcp"],
      "env": { "LDM_API_KEY": "ldm_pk_..." }
    }
  }
}

Подключение к Яндекс Алисе

Схема навыка:

1. Голос → STT (Яндекс) → текст

2. Текст → backend навыка → выбор MCP-инструмента + параметры

3. MCP tool call → /api/* LDM → ответ

4. Ответ → формулировка реплики → TTS Алисы

В роли «мозга» в backend навыка — Claude через API. Он интерпретирует свободную речь и выбирает нужный tool из MCP-списка. Это избавляет от необходимости писать grammar в навыке для каждой команды.

Аутентификация: account linking через Yandex OAuth → пользователь получает в LDM привязку к Yandex ID, навык получает Bearer-ключ с ограниченным scope (dialogs:read, dialogs:write, mailing:write, contacts:read).

Деструктивные действия (запуск рассылки, отправка письма, апдейт сделки) требуют голосового подтверждения — навык проговаривает summary и ждёт «да». Чтение и брифинг — без.

Полевой кейс: VODEXPO 2026

22 мая 2026. Москва, последний день водохозяйственной выставки. Клиент работает на стенде. Подходит ландшафтный дизайнер, просит каталог решений по водоёмам.

Клиент не за компьютером:

> Алиса, разошли каталог решений по водоёмам по всем подписавшимся 
  ландшафтным дизайнерам.

> Найдено: 247 контактов в сегменте "ландшафтные дизайнеры — подписка".
  Шаблон: "Каталог решений по водоёмам v3, май 2026". 
  Подтвердить отправку?

> Да.

> Отправляю.

Что происходит под капотом (Claude-агент в backend навыка решает выполнить такую последовательность):

bash

# 1. Резолв сегмента
GET /api/contacts?tagId=landscape-designers&subscribed=1&pageSize=500
→ 247 contacts

# 2. Резолв креатива
GET /api/creatives?search=каталог+водоёмы&latest=1
→ creativeId

# 3. Создание mailing task
POST /api/tasks
{
  "methodId": 2,
  "creativeId": "cmoue9...",
  "contactListId": "<ad-hoc>",
  "accountId": "<account>"
}
→ taskId, status: DRAFT

# 4. Self-approve (scope: mailing:write)
POST /api/mailing/$TASK_ID/approve
{ "note": "Voice-approved, designer at VODEXPO booth" }

# 5. Старт
POST /api/tasks/$TASK_ID/start
→ status: ACTIVE

20 секунд — рассылка ушла. Дальше начинается то, ради чего, собственно, всё и затевалось.

Per-message inbox verification

Стандартная схема у cold/B2B email-платформ: warm-up + inbox rotation + pre-flight inbox placement test (отправили 20 писем на seed-mailboxes до запуска, посчитали процент в инбоксе). Это статистическая оценка по сэмплу до факта.

У LDM схема другая: каждое реальное исходящее письмо после отправки верифицируется через сеть seed-mailboxes. На каждого провайдера развёрнуто 10–30 seed-ящиков (для Gmail и Outlook — около 100 каждый). Грубо схема такая: при отправке SMTP → реальный получатель параллельно создаётся test twin на seed-ящик соответствующего провайдера с теми же заголовками, body, аккаунтом-отправителем. Через IMAP опрашиваются папки INBOX vs SPAM/JUNK/Quarantine, результат пишется в поле placement диалога.

Это не идеальный proxy — seed-ящик ≠ конкретный реальный получатель, провайдер может фильтровать индивидуально по recipient-сигналам. Но это сильно лучше pre-flight теста по трём причинам:

1. Проверка идёт по каждому реальному отправлению, а не по выборке.

2. Учитывается актуальное состояние репутации в момент отправки (а не за день до запуска кампании).

3. Падение в спам у конкретного провайдера ловится в реальном времени — и срабатывает автоматический pause, если процент spam за окно превышает порог.

Endpoint, который опрашивает навык после рассылки:

bash

GET /api/dialogs/stats?taskId=$TASK_ID
{
  "total": 247,
  "placement": {
    "inbox": 231,
    "spam": 4,
    "unchecked": 12
  },
  "byProvider": {
    "gmail":   { "inbox": 142, "spam": 1 },
    "yandex":  { "inbox": 47,  "spam": 0 },
    "outlook": { "inbox": 18,  "spam": 3 },
    ...
  }
}

Алиса возвращает голосом: «Отправлено 247. В инбоксе 231, в спаме 4, ещё 12 проверяются. Outlook просел — 3 в спаме из 21».

Биллинг — за 231 inbox-доставленных. 4 спам и 16 заблокированных не тарифицируются.

Где голос работает плохо

Без маркетингового лоска. Голос покрывает 20–30% операций оператора, не больше. Остальные 70% неудобны или невозможны.

Работает хорошо:

• Утренний брифинг по входящим диалогам.

• Запуск заранее настроенной рассылки по известному сегменту.

• Ответ на конкретное входящее письмо (короткий).

• Проверка статуса доставки конкретного письма или кампании.

• Ad-hoc вопросы по статистике.

Не работает:

• Сложные многопараметрические фильтры (вроде «компании Москва + 50–500 сотрудников + e-commerce + без активности 30 дней + tag X»). Это удобнее в UI.

• HTML-вёрстка/правка креативов.

• Дизайн многошаговых пайплайнов (best-time-sending, последовательности follow-up, A/B-ветвления).

• Распознавание латинских доменов / имён компаний. Алиса систематически слышит Apple как «Эппл», Acme как «Акме». Лечится фонетической нормализацией на бэке через словарь из CRM, но точность ~70–85%, не 100%.

Хрупкие места:

• Refresh OAuth-токенов Yandex ID. Особенно если пользователь меняет пароль — навык теряет привязку, требуется переавторизация.

• Подтверждения в шумной среде. На стенде, в машине с открытыми окнами «да» распознаётся через раз.

• Латентность. Цепочка STT → Claude (intent + tool selection) → MCP → /api/* → ответ → формулировка → TTS — суммарно 4–8 секунд на типовой команде. Для email-операций приемлемо, для conversational UX чувствуется.

Tradeoffs архитектуры

MCP — это транспорт. Полезность зависит от того, что через него экспонируется. У многих CRM-платформ (HubSpot, Salesforce DX) MCP read-only или ограничен подмножеством объектов. У LDM через MCP доступна полная UI-поверхность, включая запуск рассылок и self-approve — это полезно для агентов, но требует разумной модели scope-ов и подтверждений на стороне клиента (навыка / агента).

Архитектурное решение «UI = MCP» имеет цену. Любое расширение API автоматически становится агент-callable. Это требует дисциплины — нельзя положить в /api/* что-то, что должно быть UI-only по соображениям UX или безопасности. На практике это решается scope-ами и доп. middleware для отдельных handler-ов, но это нагрузка на дизайн.

Голос как UI — узкая ниша. Это не «новый интерфейс взамен дашборда». Это дополнение для конкретных сценариев — мобильности, занятых рук, быстрого брифинга. Прибавляет ценности на 10–15% операций, не больше.

Что дальше

• MCP-сервер v2 с явной JSON Schema для каждого tool (сейчас многие возвращают свободный JSON, агенту приходится самостоятельно парсить).

• Подключение к ChatGPT MCP Apps directory.

• Voice-friendly dialogs/stats — плоский ответ, короче, без вложенных объектов, чтобы TTS не глотал секунды на проговаривании.

• Поддержка Apple Intelligence через MCP App Extensions, как только Apple откроет это для third-party (по обещаниям — Q3 2026).

Доки публичные: developers.live-direct-marketing.online. Вопросы по архитектуре / реализации — в комментариях или в почту.