У разработчика, который ведет заметки системно, Obsidian довольно быстро перестает быть папкой с markdown-файлами. Сначала там лежат ссылки и черновики, потом появляются решения по архитектуре, заметки после созвонов, правила ревью, куски документации, объяснения для будущего себя. Через несколько месяцев это уже не блокнот, а рабочая память проекта, где контекст собран раньше, чем он снова понадобится.
Синхронизация хорошо решает старую задачу: один и тот же материал должен открываться на ноутбуке, телефоне и домашнем компьютере. С AI-клиентами проблема другая. Claude Code видит репозиторий, Cursor живет внутри IDE, другие агенты тоже обычно работают с тем окружением, куда их явно пустили. Заметки в Obsidian остаются рядом, часто в соседнем окне, для помощника они все равно невидимы.
Поначалу трения почти нет. Нужен фрагмент из спецификации, вы открываете нужную страницу, копируете абзац, вставляете в чат и получаете нормальный ответ. Через какое-то время такой перенос превращается в отдельную работу: контекст не помещается в одно сообщение, заметки меняются быстрее, чем вы успеваете обновлять вставки, при переключении между проектами приходится заново вспоминать, что именно нужно показать агенту.
Где ломается ручной перенос контекста
Ручной copy-paste держится на памяти пользователя. Вы должны знать, где лежит нужный кусок, какая версия актуальна, какие договоренности были пересмотрены, какие файлы связаны между собой. Пока база небольшая, это терпимо. Когда в ней сотни заметок, десятки рабочих папок и несколько параллельных проектов, человек начинает обслуживать передачу материалов из одного инструмента в другой вместо собственной мысли.
Самый неприятный сбой возникает позже самого копирования. Агент уже получил выдержку из документа и продолжает на нее опираться, хотя исходная заметка могла измениться. В другом месте лежит решение, принятое после последнего обсуждения, в третьем сохранены ограничения по задаче, в четвертом список причин, почему прошлый подход не подошел. Без этого слоя помощник рассуждает уверенно и все равно мимо вашего проекта.
В этот момент становится понятно, что синхронизировать файлы между устройствами недостаточно. AI-клиенту нужна постоянная точка входа в рабочую базу: спросить у хранилища, что там есть, прочитать нужный документ, найти связанные записи и положить результат обратно так, чтобы человек увидел его в своем обычном Obsidian.
MCP как интерфейс к рабочей памяти
Model Context Protocol появился именно для таких связок: у AI-клиента есть задача, рядом существует внешняя система с данными, между ними нужен понятный протокол. В случае Obsidian этой внешней системой становится ваша база заметок. Агент обращается к ней через инструменты, которые предоставляет MCP-сервер: читает файл, ищет материалы по запросу, создает новую страницу, обновляет результат работы.
По смыслу это другой слой поверх синхронизации. Sync переносит изменения между устройствами. MCP открывает программный вход для клиента, который умеет сам выбирать действие. Когда Claude Code или Cursor подключены к такому серверу, заметки перестают быть текстом, который приходится носить руками, и становятся источником контекста во время работы агента.
У разных клиентов поддержка MCP может отличаться, поэтому перед настройкой все равно придется проверить конкретную версию инструмента. Общая идея остается прежней: вы перестаете каждый раз собирать выжимку для чата и даете помощнику ограниченный, авторизованный доступ к хранилищу, где уже лежит рабочая история проекта.
Как obsync проводит запрос до заметки
В obsync MCP относится к hosted-контуру. Бесплатная Community Edition решает базовую self-hosted синхронизацию, серверные интеграции требуют другого режима: платформа должна читать markdown, выполнять запросы и возвращать результат внешним клиентам. По этой причине MCP живет рядом с обычным sync-сервером, через отдельный API-домен.
Публичная точка подключения сейчас выглядит так: https://api.obsync.ru/mcp. Запросы идут по HTTP в формате JSON-RPC 2.0, авторизация устроена через Bearer token. Ключ создается в аккаунте, привязывается к одному хранилищу и не дает доступа к чужим данным. Если доступ больше не нужен, его можно отозвать в кабинете.
Права задаются через scopes. В базовой логике mcp:read разрешает читать содержимое, mcp:write дает возможность создавать и изменять файлы. Более тонкого доступа на уровне отдельных папок сейчас нет, поэтому рабочие и личные материалы лучше заранее разводить по разным хранилищам, когда вы планируете подключать к ним агента.
Когда клиент с правом записи создает заметку через MCP, obsync использует обычный поток синхронизации. Файл проходит обмен и появляется в Obsidian на подключенных устройствах. Для пользователя это выглядит как новая markdown-страница в привычной базе, только созданная внешним помощником.
REST API остается рядом, потому что решает другой класс задач. Его удобнее использовать для сценариев, где все заранее определено: веб-хуки, регулярные автоматизации, n8n, скрипты, интеграции с CRM или внутренними сервисами. MCP нужен там, где агент сам выбирает, какие операции вызвать, опираясь на ход работы и найденный контекст.
Цена server-readable режима
У такого подхода есть честная инженерная цена. Чтобы отдать заметку по API, показать ее MCP-клиенту, принять сообщение из Telegram или обработать страницу через клиппер, сервер должен видеть текст. В режиме server-readable markdown хранится так, чтобы backend мог выполнить эти операции. Интеграциям нужен читаемый материал; строгая модель нулевого доступа к содержимому со стороны сервера выбирает другой путь.
Поэтому выбор нужно делать осознанно. Если вам важнее держать инфраструктуру у себя и не включать серверные функции чтения, логичнее смотреть в сторону Community Edition и self-hosted синхронизации. Когда ценнее связать Obsidian с автоматизациями, AI-клиентами, публикацией и быстрым захватом материалов, hosted-контур с читаемой серверной копией дает больше возможностей.
Здесь нет универсально правильного варианта. Личная база с дневником, паролями и чувствительными заметками требует одного уровня осторожности. Рабочее хранилище с документацией, проектными решениями и публичными черновиками может спокойно жить в другой модели, особенно если доступы управляются через отдельные ключи, а лишние интеграции отключены.
Кому это действительно нужно
MCP начинает иметь смысл там, где Obsidian уже стал частью рабочего процесса. Если в заметках лежат coding guidelines, архитектурные решения, старые расследования, планы релизов и объяснения по продукту, агент без доступа к этой памяти постоянно будет просить вас пересказать уже записанное. С доступом через протокол он может сам найти нужный материал, прочитать его и использовать при анализе кода или подготовке документации.
Для небольшого личного блокнота такой слой часто лишний. Если вы храните список покупок, короткие идеи и пару ссылок, копирование одного абзаца в чат проще любой настройки. MCP нужен в момент, когда база знаний начинает экономить время человеку, пока AI по-прежнему работает так, будто этой базы не существует.
Сдвиг здесь простой. Синхронизация делает заметки доступными вам на разных устройствах. MCP делает ту же рабочую память доступной агенту, который помогает с кодом, текстами, исследованиями и внутренними документами. Когда оба контура сходятся, Obsidian перестает быть отдельной кладовой рядом с работой и становится частью самого рабочего процесса.