MCP — недостающий элемент между Claude Code и вашим vault Obsidian

Оригинал опубликован Chesny в X.

В 2026 году подключить кодового агента к vault Obsidian — уже не экзотическая идея. Скорее всего, это один из самых недооценённых сейчас сетапов для управления знаниями. И всё же почти все, кто так делает, остаются на первой ступени: направить Claude Code на папку и позволить ему читать и писать Markdown. Это работает. Но это только начало, и чтобы понять, почему важен следующий шаг — MCP, — сначала нужно хорошо разобраться, что у нас уже есть и где это ломается.

Что уже возможно без MCP

Когда Claude Code смотрит прямо в vault, он работает как любой агент с доступом к файловой системе: читает структуру папок, использует grep и glob, чтобы находить релевантный контент, и пишет или редактирует Markdown-файлы, соблюдая заданные ему соглашения — YAML-frontmatter, wikilinks, иерархию папок по типам контента. Нет плагина, нет базы данных, нет API: только plain text и агент, который умеет читать и писать его осмысленно.

Результат, если система хорошо спроектирована, мощнее, чем кажется. Реальный, а не гипотетический пример: vault, за которым я внимательно слежу, именно таким методом вырос с 78 сырых источников — papers, статей, документации — до 180 взаимосвязанных wiki-страниц. Из них 83 — страницы концептов, остальные — инструменты, люди, сравнения и резюме источников. Все они связаны перекрёстными ссылками, которые сам агент поддерживает в актуальном состоянии каждый раз, когда появляется новый контент. И ни одной страницы вручную никто не писал.

Потолок прямого доступа к файлам

Но у этой модели есть структурный предел, а не просто ограничение производительности. Claude Code должен заранее знать, как организован ваш vault: какая папка неизменяемая, какие есть соглашения по frontmatter, где живут концепты, а где инструменты. Каждый новый vault на практике становится отдельной интеграцией, которую нужно заново объяснять в system prompt.

Кроме того, агент не может спросить у vault: «что ты умеешь делать?». Он может только читать уже существующее и выполнять универсальные файловые операции — читать, писать, искать по тексту. Нельзя без дополнительного слоя expose-нуть ему производную операцию: «дай граф backlinks для этой заметки», «выполни этот Dataview-запрос», «скажи, какие страницы остались сиротами». Иначе агент каждый раз вынужден заново реконструировать эту логику сам, тратя контекст и увеличивая вероятность ошибки.

Что MCP решает на глубоком уровне

MCP — Model Context Protocol — это открытый стандарт, который Anthropic запустила в ноябре 2024 года именно для решения этой задачи: интеграции между ИИ-моделями и внешними системами. До MCP, если N ИИ-ассистентов должны были подключаться к M разным инструментам или источникам данных, требовалось N×M кастомных интеграций: когда одно приложение хотело поддержать Notion, оно строило поддержку с нуля; когда другому нужно было то же самое, оно снова строило её с нуля. MCP превращает N×M в N+M: создаются универсальные клиенты — по одному на приложение — и универсальные серверы — по одному на систему, — а любой клиент говорит с любым сервером без кастомной интеграции.

Правильная аналогия — USB-C. Раньше у каждого периферийного устройства был свой разъём; с USB-C устройству достаточно говорить на протоколе, и ему неважно, подключено оно к Mac или к PC.

Архитектура состоит из трёх слоёв. Host — это приложение, обращённое к пользователю: Claude Code, Claude Desktop или собственный агент. Оно интерпретирует запрос и решает, нужны ли внешние данные или инструменты. Client живёт внутри host и управляет соединением 1:1 с каждым сервером, переводя абстрактные запросы в конкретные MCP-сообщения и управляя жизненным циклом сессии. Server связывает протокол с реальной системой — в данном случае с vault Obsidian — переводя MCP-запросы в нативные операции.

Два свойства делают это чем-то большим, чем косметический слой абстракции. Первое — динамическое обнаружение возможностей: при подключении клиент спрашивает сервер, что тот умеет, и сервер отвечает в реальном времени. Если завтра сервер добавит новую функцию, клиент не нужно перепрограммировать, чтобы ею пользоваться. Второе — развязка интеллекта и данных: тот, кто строит MCP-сервер для Obsidian, не обязан знать, какая модель будет его использовать; а тот, кто строит агента, не обязан заново собирать интеграцию каждый раз, когда меняется модель.

MCP-сервер exposes три типа примитивов. Resources — это данные, которые модель может читать, но не изменять: содержимое заметки, результаты поиска, граф backlinks. Tools — это действия, которые модель может активно вызывать: создать заметку, обновить тег, выполнить структурированный запрос. Prompts — переиспользуемые и параметризуемые шаблоны инструкций, например «суммируй этот источник и создай соответствующую wiki-страницу» как именованная операция, а не как свободный текст, который каждый раз нужно переписывать.

Применительно к Obsidian — конкретно

Уже существуют MCP-серверы, построенные специально для Obsidian внутри его open-source-экосистемы. Обычно они опираются на локальный REST API-плагин Obsidian и expose-ят операции вроде семантического поиска по vault, создания и редактирования заметок, управления тегами и метаданными или чтения графа ссылок — без необходимости, чтобы агент заранее знал точную структуру папок.

Практическое изменение тонкое, но важное: без MCP Claude Code администрирует ваш vault по правилам, которые вы ему объяснили по одному. С MCP ваш vault превращается в инструмент, которым Claude Code может оперировать так же, как API или базой данных, обнаруживая его возможности в момент подключения, а не заранее запоминая их. И то же самое соединение подходит любому другому MCP-клиенту, не только Claude Code: тот же сервер мог бы кормить другого агента в другом приложении без единой правки кода на стороне Obsidian.

Практическая рамка: три уровня зрелости

Чтобы понять, где находится ваш собственный сетап, я использую такую рамку:

Уровень 0: копировать и вставлять контекст вручную. Каждый разговор начинается с нуля; пользователь вставляет в чат релевантные фрагменты своих заметок. Для разовых задач работает, но не масштабируется.

Уровень 1: агент с прямым доступом к файлам. Здесь сегодня находится большинство сетапов Claude Code + Obsidian, включая пример 78→180 страниц из этой статьи. Агент читает и пишет vault напрямую, следуя соглашениям, описанным в файле инструкций. Это уже существенно мощнее уровня 0, и для одного vault, которым управляет один агент, такого подхода может хватить надолго.

Уровень 2: агент, подключённый через MCP. Vault expose-ится как сервер с динамически обнаруживаемыми возможностями, переиспользуемыми между разными моделями и приложениями. Это начинает иметь смысл, когда появляется больше одного агента, больше одного vault или необходимость expose-ить операции, выходящие за пределы чтения и записи отдельных файлов.

Не обязательно сразу прыгать на уровень 2, чтобы получить пользу от vault, управляемого ИИ. Уровень 1 уже является настоящим скачком по сравнению с отсутствием системы. Но понять, что решает MCP, — значит понять, куда всё движется: от «мой ИИ может читать мои заметки» к «моё знание — это система, которой может оперировать любой ИИ».

А на каком уровне сейчас ваш собственный сетап? Напишите в комментариях. Если будет достаточно интереса, следующая часть будет пошаговым разбором того, как поднять первый MCP-сервер для Obsidian.

И если это было полезно, подписывайтесь на @chesny.

Это только первая статья серии об агентах, которые перестают читать системы и начинают ими оперировать.