Все статьи
5 августа 2026 г.·4 мин чтения

Скиллы, инструменты и MCP в Open WebUI: что из этого зачем

Чем скиллы Open WebUI отличаются от инструментов и функций, как устроен SKILL.md, как подключаются MCP-серверы и где в этой схеме проходит граница локальности.

В Open WebUI четыре разных способа расширить поведение модели: инструменты, функции, пайплайны и скиллы. Плюс отдельно MCP. Названия соседние, документация разнесена по разделам, и на практике люди подключают не то, что нужно.

Разница между ними простая, если один раз её проговорить.

Скиллы: это текст, а не код

Скилл — набор инструкций в markdown. Не скрипт, не API, а документ, который объясняет модели, как подходить к задаче: правила код-ревью, требования к стилю текста, порядок разбора инцидента.

Устроен как папка с файлом SKILL.md. Если в начале файла лежит YAML-фронтматтер с полями name и description, интерфейс подхватит их автоматически:

---
name: code-review-guidelines
description: Step-by-step instructions for thorough code reviews
---

# Code Review Guidelines

Рядом можно положить подпапки references/, templates/, scripts/ и assets/.

Вызывается скилл двумя способами: упоминанием через $ прямо в чате — тогда содержимое подставляется сразу целиком — или привязкой к модели в её настройках, чтобы он был доступен всегда. Загружаются они постепенно: модель сначала видит только каталог с описаниями, а полный текст подтягивается при активации. Это сделано ради контекста, и для локальных моделей такая экономия важнее, чем для облачных.

Главное свойство: чтобы написать скилл, не нужен Python. Если умеешь писать документ, умеешь делать скиллы. Тот же принцип разбираем в статье про навыки для ИИ-агента.

Инструменты и функции: это код

Инструменты и функции — питоновские скрипты, которые выполняются в чате. Для них внутри есть редактор кода, так что писать можно прямо в интерфейсе.

Разница с скиллами принципиальная. Скилл меняет то, как модель думает: даёт ей инструкцию и контекст. Инструмент даёт ей новое действие: сходить в API, посчитать, что-то записать. Путать их — типичная ошибка. Если задача звучит «пусть отвечает по нашему регламенту», это скилл. Если «пусть проверяет статус заказа в нашей системе», это инструмент.

Пайплайны стоят отдельно: это модульный фреймворк для фильтров, провайдеров и своей логики, уровнем ниже и для более сложных сценариев.

MCP

Open WebUI поддерживает MCP-серверы напрямую, через Streamable HTTP. То есть готовый сервер инструментов подключается без написания собственных функций под каждую интеграцию.

Логика та же, что в других хостах: сервер объявляет список инструментов, хост показывает их модели, модель просит вызвать, выполняет хост. Устройство протокола разобрано в статье что такое MCP, а подключение в других приложениях — в материалах про MCP в LM Studio и MCP в llama.cpp.

Практический совет тот же, что и везде: не подключай всё сразу. Описания инструментов занимают контекст на каждом запросе, и локальная модель на восьми тысячах токенов упирается в предел быстрее, чем ты успеваешь удивиться.

Если модель начала путать аргументы инструментов или вызывать не тот сервер, первым делом отключи половину серверов, а не меняй модель. В девяти случаях из десяти дело в перегруженном контексте.

Что выбрать под задачу

НужноБерёшь
Модель должна следовать твоим правиламСкилл
Модель должна выполнить действие в своей системеИнструмент или функцию
Подключить готовую интеграциюMCP-сервер
Встроить свою логику в обработку запросовПайплайн

Где здесь граница локальности

Про это стоит сказать прямо, потому что «локальный интерфейс» вводит в заблуждение.

Локальным остаётся то, что физически считается и хранится у тебя: модель, история чатов, база знаний. Всё остальное зависит от того, что ты подключил. MCP-сервер GitHub обращается к GitHub. Инструмент, который ходит в чужой API, отправляет туда данные. Скилл сам по себе наружу не ходит — это просто текст, — но текст этот попадает в контекст модели, и если модель облачная, он уедет вместе с запросом.

Локальный MCP-клиент не делает облачный сервис локальным. Проверять надо всю цепочку: где считается модель, какие серверы включены и куда ходит каждый из них.

Чего не даёт даже полный набор

Собери всё вместе — скиллы, инструменты, MCP, пайплайны — и получится очень настраиваемый чат. Модель будет знать твои правила и уметь дёргать твои системы.

Чего не появится: исполнителя. Open WebUI живёт в браузере и работает с тем, что ты в него загрузил. Задачи вида «пройди по проекту на диске, найди и почини» требуют доступа к файловой системе и терминалу той машины, где всё это лежит, — и способности вести задачу через несколько шагов с проверкой результата.

Дока устроена как такой исполнитель. Она работает с файлами там, где они лежат, выполняет команды, подключает MCP-серверы и позволяет описывать свои навыки тем же текстом, что и скиллы Open WebUI, — но результат этих навыков применяется к твоим файлам, а не остаётся сообщением в чате.

Если ты уже настроил Open WebUI под себя, поставь Доку рядом и прогони на ней ту задачу, из-за которой обычно приходится копировать ответы вручную. Это самая наглядная проверка разницы между настраиваемым чатом и агентом.