Obsidian MCP подключают через плагин сообщества Local REST API: он поднимает на вашем компьютере защищённый интерфейс к vault, а встроенный или сторонний MCP-сервер даёт агенту поиск, чтение и запись заметок. Сам Obsidian MCP из коробки отсутствует, поэтому границы доступа задаёте вы. Связка подходит, когда заметки хранятся локально и агенту допустимо видеть выделенный vault целиком.
Что за мост
Мост между Obsidian и агентом строится на плагине Local REST API; по описанию плагина, он содержит встроенный MCP-сервер по адресу https://127.0.0.1:27124/mcp/ с авторизацией ключом API.
Сценарий для проверки: аналитик собрал в vault заметки по интервью с клиентами и просит агента найти повторяющиеся жалобы, указав заметку-источник для каждой. Свод агент кладёт в отдельную заметку-черновик с перечнем источников, а аналитик читает его рядом с оригиналами. Заметки с интервью остаются нетронутыми, поэтому ошибку модели можно найти и откатить.
Локальная схема удобна тем, что заметки остаются на компьютере, а во внешний сервис уходит только то, что агент решил процитировать в диалоге с моделью. Тем важнее знать, какой именно клиент и какая модель получают эти цитаты: правила обработки данных у них свои. Плагин выступает как защищённый REST-интерфейс к vault. Он умеет читать, создавать, изменять и удалять файлы, править отдельные разделы по заголовкам, ссылкам на блоки и свойствам, искать по тексту и выполнять команды Obsidian. Отдельные серверы сообщества, такие как mcp-obsidian, ходят в vault через тот же интерфейс. Для пилота хватает встроенного сервера плагина: меньше звеньев, меньше мест для ошибки. Выбирая реализацию, смотрите, какие именно инструменты она выдаёт агенту: от этого зависит всё остальное.
Границы vault
Заметки обычно хранят больше, чем помнит автор: контакты клиентов, обрывки договорённостей, личные записи рядом с рабочими. Главный вопрос безопасности: что именно лежит в хранилище, к которому получит доступ агент. Об ограничении доступа по папкам описание плагина молчит, поэтому надёжной границей служит сам vault. Заведите отдельный vault для рабочего пилота, назначьте ему владельца и скопируйте в него только заметки, предназначенные для задачи. Личные дневники, пароли и документы с персональными данными остаются вне такого vault.
- Отдельный vault под пилот вместо рабочего архива за все годы.
- Ключ API хранится в менеджере секретов; в заметках его нет.
- Плагин слушает локальный адрес, порт закрыт для внешней сети.
- Список инструментов сервера проверен: команды Obsidian (
command_execute) и удаление файлов (vault_delete) отключены на стороне клиента.
Для агента это означает, что клиенту потребуется доверять сертификату плагина, и настройка такого доверия делается один раз под пилот. При первом запуске плагин создаёт собственный центр сертификации и выдаёт сертификат для локального адреса; его скачивают со страницы плагина и добавляют в доверенные. Для пилота этого достаточно, а доступ с другого компьютера требует отдельного решения владельца безопасности. В настройках можно включить и обычный HTTP на порту 27123, но для пилота оставляйте только HTTPS. Разрешения для сервера в целом сверяйте по общей статье про доступ MCP к папкам.
Поиск с источником
Результат поиска по заметкам легко открыть глазами, и проверка строится на этом: любой вывод агента сопровождается путём к файлу и цитатой. Плагин поддерживает полнотекстовый поиск и структурные запросы, поэтому агент находит кандидатов, а сотрудник открывает каждую заметку и сверяет формулировку.
- Подготовьте тестовый vault с пятью вымышленными заметками об интервью, где одна жалоба повторяется в трёх из них.
- Попросите агента найти повторяющуюся жалобу и перечислить заметки с цитатами.
- Откройте каждую названную заметку в Obsidian и убедитесь, что цитата стоит в файле дословно.
- Проверьте обратное: заметка с той же жалобой, но другими словами, должна попасть в список, а вымышленная жалоба исключена из списка.
Результаты проверки сохраняйте вместе с версией инструкции и набором инструментов, чтобы следующий прогон сравнивался с этим. Расхождения записывайте: пропущенная заметка указывает на слабый поиск, придуманная цитата — на генерацию без опоры на файл. Пропуск обнаруживается при чтении, а выдумка выглядит убедительно, поэтому второй случай опаснее, и при его повторении запись для агента остаётся закрытой. Добавьте в проверку заметку-ловушку: файл, где жалоба упомянута мимоходом в одном абзаце. Агент, который читает файлы целиком, её найдёт, а агент, который опирается на заголовки, пропустит. Результат подсказывает, какой инструмент поиска оставить в наборе. Заметки с общими знаниями удобно связывать с памятью агента через MCP, но проверка источника остаётся прежней.
Какие заметки вашей команды хочется сделать доступными агенту?
Безопасная запись
Задолго до первых жалоб зафиксируйте политику: кто включает запись, кто просматривает черновики и в какой срок пустеет папка. Запись открывайте после того, как поиск с источниками прошёл проверку. Самый безопасный вариант — создание новой заметки в выделенной папке черновиков. Править существующие заметки через частичную правку по заголовку допустимо лишь для служебных разделов, где ошибка видна сразу.
| Операция | Риск | Правило |
|---|---|---|
| Создание заметки-черновика | Низкий: новый файл | Разрешить в папке «Черновики агента» |
| Правка раздела по заголовку | Средний: меняется чужой текст | Только для служебных заметок, с просмотром результата |
| Перезапись файла целиком | Высокий: теряется прежний текст | Закрыть для агента |
| Удаление файла | Высокий: исчезает источник | Закрыть для агента |
| Выполнение команд Obsidian | Широкий: действие зависит от команды | Убрать из набора инструментов |
Черновик получает ту же структуру, что и рабочие заметки: заголовок, дату, список заметок-источников со ссылками. Эти ссылки превращают результат в проверяемый документ с видимыми следами. Каждое изменение сотрудник просматривает до сохранения в основном vault: переносит нужное из черновика сам. Так агент готовит текст, а ответственность за содержимое базы знаний остаётся у владельца. Доступ к свойствам заметки (frontmatter) считайте записью повышенного риска: по ним строятся запросы и плагины, и ошибка в них ломает отбор.
Резерв и откат
Любой пилот с записью начинается с резервной копии, и этот шаг записывается в чек-лист запуска рядом с проверкой ключа. Перед первой записью сделайте копию vault и убедитесь, что восстановление работает: откройте копию в Obsidian и сравните число заметок. Для текстовых заметок хорошо подходит система контроля версий: каждое изменение агента видно построчно, и откат занимает одну команду. Синхронизация между устройствами откату противопоказана: она распространяет ошибку на все копии.
Отдельно решите, кто имеет право переносить текст из черновика в основной vault. Обычно это автор заметок, потому что только он отличает уточнение от искажения своей мысли. Журнал записей ведите отдельно от vault, чтобы его нельзя было испортить тем же агентом: время, сотрудник, путь к заметке, тип операции и ссылка на версию. Ключ API плагина меняйте при смене владельца пилота и после любого подозрения на утечку; после замены проверьте, что старый ключ перестал работать. Через период работы пересмотрите набор инструментов и список заметок в пилотном vault: устаревшие материалы убирайте, чтобы агент опирался на актуальное. Часто выясняется, что для задачи хватает поиска и создания черновиков.
Установите плагин в пустой тестовый vault, отключите команды и удаление, затем прогоните поиск с цитатами по пяти вымышленным заметкам. Запись добавляйте последним шагом и только в папку черновиков. Если база знаний общая и нужны права и приёмка, обсудите с нами ИИ-агента для вашей базы знаний.