Флаги компонентов

Neva использует флаги компонентов Cargo, чтобы сократить время компиляции и минимизировать размер бинарного файла — компилируется только тот код, который действительно нужен. На этой странице описаны все доступные компоненты и способы их комбинирования для типичных сценариев.

Быстрый старт

Для большинства проектов достаточно готовых пресетов:

[dependencies]
# Полнофункциональный MCP-сервер
neva = { version = "...", features = ["server-full"] }

# Полнофункциональный MCP-клиент
neva = { version = "...", features = ["client-full"] }

# Сервер и клиент одновременно
neva = { version = "...", features = ["full"] }

Справочник компонентов

Пресеты

Компонент	Включает	Описание
full	server-full + client-full	Всё сразу — для приложений, которые запускают и сервер, и клиент
server-full	server-macros, tracing, http-server-volga, server-tls, server-oauth, di, tasks, apps, registry	Все возможности сервера, включая HTTP-сервер по умолчанию на базе Volga
client-full	client-macros, tracing, http-client, client-tls, client-oauth, client-oauth-jwt, client-oauth-dpop, tasks, apps	Все возможности клиента

Обратите внимание: full — это все компоненты, кроме двух: флага поколения протокола (см. ниже) и svir, который остаётся опциональным, пока svir в версии 0.x. full — это сборка по умолчанию; docs.rs публикует её с svir сверху.

Компоненты сервера

Компонент	Включает	Описание
server	—	Базовая среда выполнения сервера: регистрация обработчиков инструментов, ресурсов и промптов, транспорт stdio
server-macros	server, macros	Добавляет атрибутные макросы (#[tool], #[resource], #[prompt] и др.)
http-server	server	Абстракции потокового HTTP-транспорта, не привязанные к конкретному фреймворку — не тянет за собой HTTP-стек. Подключите свой (axum, hyper, actix-web, …), реализовав HttpEngine
http-server-volga	http-server	Адаптер HTTP-сервера по умолчанию на базе Volga, включая JWT-аутентификацию
server-tls	http-server-volga	Поддержка TLS для HTTP-сервера по умолчанию, включая автоматическую генерацию сертификата для разработки
server-oauth	http-server	OAuth 2.1: метаданные защищённого ресурса и проверка токенов на сервере
registry	server	Манифесты server.json для MCP Registry: генерируются из приложения и крейта и проверяются до публикации. Только типы и валидатор — новых зависимостей не тянет

Компоненты клиента

Компонент	Включает	Описание
client	—	Базовая среда выполнения клиента: вызов инструментов, чтение ресурсов, получение промптов, транспорт stdio
client-macros	client, macros	Добавляет атрибутные макросы (#[sampling], #[elicitation])
http-client	client	Потоковый HTTP-транспорт и поддержка SSE-потоков
client-tls	—	Поддержка TLS для HTTP-клиента (rustls)
client-oauth	http-client	Авторизация OAuth 2.1 на стороне клиента: discovery, все три механизма регистрации, authorization code + PKCE, client credentials и JWT bearer
client-oauth-jwt	client-oauth	Аутентификация клиента через private_key_jwt — клиент подписывает короткоживущее утверждение собственным ключом вместо общего секрета. Единственная часть OAuth-клиента, которой нужен JWS-бэкенд, поэтому она отдельная
client-oauth-dpop	client-oauth	DPoP: токены, привязанные к отправителю (RFC 9449) — каждый токен привязан к ключу клиента и доказывается на каждом запросе

Общие компоненты

Компонент	Описание
macros	Инфраструктура процедурных макросов (общая для server-macros и client-macros)
di	Внедрение зависимостей — контейнер сервисов с жизненными циклами singleton, scoped и transient
tasks	Задачи с расширенными запросами — долгосрочное асинхронное выполнение инструментов с опросом
apps	MCP Apps (SEP-1865) — HTML-ресурсы ui:// и блоки _meta.ui, привязывающие к ним инструмент. Аддитивна и не тянет новых зависимостей. Серверной половине нужно поколение протокола по умолчанию; клиентская работает в обоих
tracing	Структурированное логирование через экосистему tracing и MCP-уведомления журнала

Мост svir

Компонент

Описание

svir

Отдаёт инструменты MCP модели как Toolbox из svir — инструменты подключённого сервера через RemoteTools, собственные инструменты сервера через App::into_toolbox и ctx.tools().toolbox(), — а также превращает промпты, ресурсы и сэмплирование в типы svir. Работает с сервером, клиентом или обоими. svir подключается без своих компонентов по умолчанию, поэтому, чтобы обращаться к модели, добавьте svir в собственные зависимости

svir не входит ни в один пресет: svir пока в версии 0.x, и пресет, включающий его, превращал бы каждый ломающий релиз svir в ломающий релиз neva. Укажите его рядом с пресетом:

neva = { version = "...", features = ["full", "svir"] }
svir = "0.1.4"

Поколение протокола

Компонент	Описание
legacy-spec	Переключает сборку с MCP 2026-07-28 (поколение по умолчанию) обратно на предыдущее — MCP 2024-11-05 … 2025-11-25

legacy-spec — переключатель, а не добавка

Включение legacy-spec компилирует поверхность 2026-07-28 прочь — два поколения никогда не сосуществуют в одной сборке. А поскольку флаги Cargo аддитивны, --all-features включает его и потому проверяет именно легаси-профиль; профилю по умолчанию нужен явный список, например --features "server-full client-full". См. Легаси-спецификация.

Типовые конфигурации

Минимальный stdio-сервер (без макросов)

neva = { version = "...", features = ["server"] }

Используйте этот вариант, когда предпочитаете регистрировать обработчики вручную с помощью map_tool(), map_resource() и map_prompt() вместо атрибутных макросов.

Сервер с макросами, без HTTP

neva = { version = "...", features = ["server-macros", "tracing"] }

Атрибутные макросы и логирование без HTTP-транспорта. Подходит для серверов, работающих только через stdio.

HTTP-сервер без TLS

neva = { version = "...", features = ["server-macros", "http-server-volga", "tracing", "di", "tasks"] }

HTTP-транспорт по умолчанию (на базе Volga) без TLS — подходит для локальных или внутренних развёртываний за обратным прокси.

HTTP-сервер на собственном стеке (axum / hyper / actix-web)

neva = { version = "...", features = ["server-macros", "http-server", "tracing", "di", "tasks"] }
# плюс выбранный вами фреймворк
axum = "0.8"

Флаг http-server поставляет только абстракции, не привязанные к конкретному фреймворку — без Volga и без зависимостей от HTTP-стеков. Вы реализуете HttpEngine для своего стека и подключаете его через HttpServer::from_engine(...). Полное руководство — в разделе Свой HTTP-стек.

Минимальный HTTP-клиент

neva = { version = "...", features = ["http-client"] }

Лёгкий клиент для подключения к удалённым MCP-серверам по HTTP, без макросов и трассировки.

Сервер со встроенным клиентом (паттерн агента)

neva = { version = "...", features = ["server-full", "http-client"] }

MCP-сервер, который также выступает клиентом — например, сервер, делегирующий запросы на сэмплирование или распределяющий их по другим MCP-серверам.

Компоновка компонентов

На диаграмме ниже показано, как компоненты зависят друг от друга:

full
├── server-full
│   ├── server-macros
│   │   ├── server
│   │   └── macros
│   ├── http-server-volga
│   │   └── http-server
│   │       └── server
│   ├── server-tls
│   │   └── http-server-volga
│   ├── server-oauth
│   │   └── http-server
│   ├── tracing
│   ├── di
│   ├── tasks
│   ├── apps
│   └── registry
│       └── server
└── client-full
    ├── client-macros
    │   ├── client
    │   └── macros
    ├── http-client
    │   └── client
    ├── client-tls
    ├── client-oauth
    │   └── http-client
    ├── client-oauth-jwt
    │   └── client-oauth
    ├── client-oauth-dpop
    │   └── client-oauth
    ├── tracing
    ├── tasks
    └── apps

svir          (опционален, ни в одном пресете: мост к модели для сервера, клиента или обоих)
legacy-spec   (ортогонален: выбирает поколение протокола, а не возможность)