Скиллы, инструменты и 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 под себя, поставь Доку рядом и прогони на ней ту задачу, из-за которой обычно приходится копировать ответы вручную. Это самая наглядная проверка разницы между настраиваемым чатом и агентом.