MCP для Obsidian: как подключить заметки к ChatGPT, Claude и Cursor

Я довольно долго использовал Obsidian и LLM совершенно независимо друг от друга. В Obsidian лежали рабочие заметки, архитектурные решения, идеи для статей, планы проектов и вся накопленная за годы база знаний. В Cursor и ChatGPT я работал с кодом и задавал вопросы моделям.

Связь между этими двумя мирами обеспечивал я сам.

Открыл Obsidian, нашёл заметку, скопировал нужный кусок, вставил в LLM, получил ответ, иногда скопировал результат обратно. Каждая такая операция занимает несколько секунд, поэтому долго не воспринимается как проблема. Но когда делаешь это много раз в день, постепенно понимаешь, что работаешь человеком-адаптером между двумя системами.

В какой-то момент мне это надоело, и я написал собственный MCP-сервер для Obsidian — Obsidian Agent.

Он даёт LLM доступ к Obsidian vault: модель может искать заметки, читать их, смотреть структуру хранилища и, если разрешить, создавать или изменять файлы.

Сам проект оказался довольно небольшим. Гораздо интереснее оказался вопрос, который возник в процессе: как вообще правильно давать LLM доступ к собственной базе знаний и насколько много ей стоит разрешать?

С этого и начнём.

Что такое MCP для Obsidian

MCP, или Model Context Protocol, — открытый протокол, через который LLM-клиент может работать с внешними инструментами и данными.

Если сильно упростить, без MCP работа выглядит так:

Obsidian
   ↓
человек копирует текст
   ↓
ChatGPT / Claude / Cursor
   ↓
LLM

С MCP между клиентом и данными появляется сервер:

Obsidian Vault
      ↓
  MCP Server
      ↓
ChatGPT / Claude / Cursor
      ↓
     LLM

MCP-сервер описывает доступные модели инструменты. Например:

read_note
search_notes
list_files
create_note
update_note

Когда пользователь пишет:

Найди мои заметки про PostgreSQL и напомни, почему я отказался от предыдущей архитектуры.

модель не обязана заранее получать весь Obsidian vault в контекст.

Она может сначала вызвать поиск, получить несколько подходящих файлов, прочитать нужные заметки и уже после этого сформировать ответ.

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

Что можно делать с Obsidian через MCP

Самый очевидный сценарий — поиск по заметкам.

Например:

Найди всё, что я писал про MCP.

Или:

Покажи заметки, где упоминается Redis.

Но обычный поиск уже есть внутри самого Obsidian, поэтому ради него одного городить MCP особого смысла нет.

Интереснее становится на следующем шаге, когда найденные данные можно сразу использовать.

Например:

Найди все мои заметки про MCP и собери список нерешённых технических вопросов.

Или:

Прочитай заметки по проекту и составь черновик README.

Или:

Найди все упоминания проекта за последний месяц в daily notes и сделай краткое резюме.

Или:

Посмотри мои старые архитектурные заметки и сравни их с текущим решением.

В этом случае модель выполняет уже небольшую последовательность действий:

задача
  ↓
поиск
  ↓
выбор нужных файлов
  ↓
чтение
  ↓
анализ
  ↓
ответ

Если разрешить запись, цепочка может продолжиться:

анализ
  ↓
создание или изменение заметки

И здесь Obsidian постепенно перестаёт быть просто архивом Markdown-файлов. Он становится внешней памятью, с которой может работать агент.

Какие вообще есть способы подключить MCP к Obsidian

Здесь начинается путаница, потому что под названием «Obsidian MCP» сейчас существует сразу несколько разных подходов.

В общих чертах их можно разделить на четыре варианта.

Подход	Как работает	Плюсы	Ограничения
Прямой доступ к файлам	MCP читает Markdown-файлы vault напрямую	Просто, быстро, Obsidian можно не запускать	Нет доступа к внутреннему состоянию Obsidian
Local REST API	MCP обращается к плагину REST API внутри Obsidian	Можно работать через API приложения	Нужен плагин и запущенный Obsidian
MCP-плагин	MCP-сервер запускается прямо внутри Obsidian	Доступ к active note, metadata, backlinks и API Obsidian	Сервер зависит от приложения
Obsidian CLI	MCP вызывает официальный CLI	Официальный интерфейс автоматизации	Obsidian должен быть запущен

Нельзя сказать, что один вариант правильный, а остальные неправильные. Они просто решают немного разные задачи.

Прямой доступ к Markdown

Это самый простой вариант и тот, который я выбрал для своего проекта.

Obsidian vault — обычная директория:

Vault/
├── Projects/
├── Research/
├── Daily/
├── Ideas/
└── Books/

Внутри лежат обычные .md-файлы.

Значит, чтобы прочитать заметку, необязательно разговаривать с самим Obsidian.

Можно смонтировать директорию в Docker-контейнер и работать непосредственно с файлами.

Получается:

Vault
  ↓
filesystem
  ↓
MCP Server
  ↓
LLM client

Плюс этого решения в том, что Obsidian вообще может быть закрыт.

Серверу всё равно, каким редактором я открываю Markdown.

Есть и минус: MCP-сервер не знает внутреннего состояния приложения. Он не понимает, какая вкладка сейчас открыта, какие плагины установлены или какой файл находится в active view.

Для моей задачи это оказалось нормальным компромиссом.

Local REST API

Другой популярный вариант — установить в Obsidian плагин Local REST API, а MCP-сервер сделать адаптером между API и LLM.

Архитектура получается такой:

LLM
 ↓
MCP Server
 ↓
Local REST API
 ↓
Obsidian
 ↓
Vault

Так работает один из наиболее распространённых вариантов mcp-obsidian.

Плюс в том, что интеграция проходит через Obsidian.

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

MCP как плагин Obsidian

Есть и более тесный вариант: сам MCP-сервер запускается внутри Obsidian как community plugin.

В этом случае ему уже доступны специфичные для приложения возможности: активная заметка, backlinks, tags, frontmatter, attachments и другие сущности Obsidian.

Это хороший вариант, если AI должен понимать не только содержимое vault, но и состояние самого приложения.

Obsidian CLI

В 2026 году появился ещё один интересный вариант — официальный Obsidian CLI.

Через него можно программно искать, читать и изменять заметки:

obsidian search query="MCP"
obsidian read
obsidian daily

Для новых интеграций это особенно интересно, потому что между MCP-сервером и Obsidian появляется официальный интерфейс вместо стороннего REST API.

Но есть важное ограничение: CLI работает через запущенный Obsidian.

Я свой проект начинал ещё с более простой идеи — если Markdown уже лежит на диске, читать его напрямую.

Почему я выбрал прямой доступ к файлам

Изначально я сформулировал задачу довольно узко.

Мне не нужен был «AI внутри Obsidian».

Мне хотелось иметь доступ к своим заметкам там, где я уже работаю.

Например, я нахожусь в Cursor и пишу код. В какой-то момент нужно вспомнить решение, которое я фиксировал несколько месяцев назад.

Мне не хочется:

1. переключаться в Obsidian;
2. вспоминать название заметки;
3. искать её;
4. копировать текст;
5. возвращаться в Cursor;
6. вставлять контекст.

Гораздо естественнее написать:

Посмотри мои заметки по этому проекту и найди, что я писал про эту проблему.

Поэтому Obsidian для меня в этой архитектуре остаётся редактором и интерфейсом к базе знаний.

Сам vault — хранилищем.

MCP — слоем доступа.

LLM-клиент — интерфейсом для работы с моделью.

Так появился Obsidian Agent.

Как устроен мой MCP-сервер для Obsidian

Архитектуру проекта я специально оставил небольшой:

obsidian-agent/
├── app/
│   ├── mcp/
│   │   └── server.py
│   └── vault/
│       └── service.py
├── tests/
├── Dockerfile
├── docker-compose.yml
└── pyproject.toml

VaultService ничего не знает про LLM.

Он выполняет обычные операции с файлами.

MCP-слой оборачивает эти операции в tools, которые видит клиент.

Сейчас модель получает шесть основных инструментов:

vault_ls
vault_read
vault_write
vault_glob
vault_tree
vault_search

vault_ls показывает содержимое директории.

vault_read читает Markdown-файл.

vault_write создаёт или перезаписывает заметку.

vault_glob ищет файлы по маске.

vault_tree возвращает структуру vault.

vault_search выполняет полнотекстовый поиск.

На первый взгляд хочется добавить ещё двадцать инструментов. На практике я пришёл почти к обратному выводу.

Чем меньше tools, тем предсказуемее работает модель

При проектировании API для разработчика обычно удобно иметь выразительные методы.

С LLM появляется дополнительный фактор: выбирать метод будет сама модель.

Если предоставить ей:

read_note
read_notes
get_note
get_notes
find_note
find_notes
search_note
search_notes

вы создали не богатый API, а задачу классификации.

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

Я поэтому старался делать tools достаточно примитивными и с понятными границами.

Нужно прочитать файл — vault_read.

Нужно найти текст — vault_search.

Нужно выбрать группу файлов по структуре — vault_glob.

Нужно посмотреть дерево — vault_tree.

Вместо одного огромного «умного» инструмента модель получает несколько простых примитивов и сама собирает из них последовательность действий.

В каком-то смысле правила хорошего API здесь остаются прежними. Просто новым потребителем API становится LLM.

Почему glob оказался неожиданно полезным

Один из инструментов, который сначала казался мне второстепенным, — vault_glob.

Допустим, структура базы знаний выглядит так:

Daily/
├── 2024/
├── 2025/
└── 2026/

Без glob модель может начать исследовать её последовательно:

vault_ls("")
vault_ls("Daily")
vault_ls("Daily/2026")
...

Чем больше vault, тем больше появляется лишних вызовов.

С glob можно сразу запросить:

Daily/2026/**/*.md

или:

Projects/**/*.md

или:

**/*mcp*.md

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

Загружать больше информации далеко не всегда полезно.

Иногда лучше дать модели способ точнее выбрать нужную.

Как подключить Obsidian MCP к Cursor

Для локального использования я предпочитаю stdio.

MCP-клиент сам запускает процесс сервера и общается с ним через stdin/stdout.

В моём случае сервер работает внутри Docker:

git clone https://github.com/tenqz/obsidian-agent.git
cd obsidian-agent

docker build -t obsidian-agent-mcp .

После этого сервер можно добавить в MCP-конфигурацию клиента:

{
  "mcpServers": {
    "obsidian-vault": {
      "command": "docker",
      "args": [
        "run",
        "--rm",
        "-i",
        "-e", "MCP_TRANSPORT=stdio",
        "-v", "/path/to/your/vault:/vault",
        "obsidian-agent-mcp"
      ]
    }
  }
}

Вместо:

/path/to/your/vault

нужно указать реальную директорию Obsidian vault.

После перезапуска клиента становятся доступны MCP tools.

Можно проверить соединение простым запросом:

Покажи структуру моего Obsidian vault.

Если всё настроено правильно, модель вызовет vault_tree.

Следующий запрос уже интереснее:

Найди все заметки, в которых упоминается Model Context Protocol.

Здесь будет использован vault_search.

А дальше можно дать задачу более высокого уровня:

Найди заметки про MCP, прочитай их и составь список идей, которые я ещё не реализовал.

Именно последний вариант лучше всего показывает, зачем вообще понадобилась интеграция.

Как подключить Obsidian MCP к Claude

Для Claude Desktop локальная схема практически такая же.

Клиент умеет запускать MCP-сервер через stdio, поэтому сервер остаётся локальным:

Claude Desktop
      ↓ stdio
Docker / MCP Server
      ↓
Obsidian Vault

Мне этот вариант особенно нравится для личной базы знаний.

Нет публичного endpoint, не нужен домен, не нужно отдельно настраивать OAuth. Сервер получает доступ только к той директории, которую я явно передал Docker-контейнеру.

При этом важно помнить, что локальность MCP-сервера и локальность самой LLM — разные вещи.

MCP может локально читать файл, но содержимое, которое модель использует для ответа, всё равно передаётся LLM-провайдеру в соответствии с правилами конкретного клиента.

Если в vault лежат секреты, персональные данные или рабочая информация под NDA, этот момент нельзя игнорировать.

А что с ChatGPT

Здесь схема отличается.

Cursor и Claude Desktop могут непосредственно запустить локальный MCP-процесс через stdio.

ChatGPT не подключается к такому локальному subprocess напрямую. Для него нужен удалённо доступный MCP-сервер либо специальный защищённый механизм подключения к приватной инфраструктуре.

Поэтому архитектура становится сетевой:

Obsidian Vault
      ↓
MCP Server
      ↓
HTTPS
      ↓
ChatGPT

И именно здесь требования к безопасности резко возрастают.

Первая версия моего сервера использовала для сетевого подключения SSE и OAuth 2.1 с PKCE. Пока я развивал проект, успела измениться сама спецификация MCP.

В актуальной спецификации MCP 2026-07-28 старый HTTP+SSE transport уже считается legacy, а основной путь для сетевых серверов сместился к современному HTTP-взаимодействию. Dynamic Client Registration, который использовался в ранних OAuth-сценариях MCP, тоже постепенно выводится из основной архитектуры.

Поэтому старую SSE-конфигурацию из первой версии проекта я сейчас не считаю хорошей рекомендацией для новой установки.

Локальный stdio остаётся нормальным вариантом.

Сетевую часть проекта я бы уже строил под актуальную версию MCP.

Есть ещё одно ограничение со стороны самого ChatGPT: на сентябрь 2026 года возможности custom MCP зависят от тарифа. Полная работа с write/modify actions разворачивается для Business, Enterprise и Edu, а возможности других планов могут быть ограничены чтением и поиском.

Поэтому если цель — именно ChatGPT, нужно отдельно проверить текущую доступность MCP в вашем плане и использовать сервер с современным remote transport.

Нужно ли вообще давать AI право изменять заметки

Читать базу знаний модели дать психологически довольно легко.

Запись — совершенно другой уровень доверия.

У меня есть:

vault_write

и технически модель может создать или полностью перезаписать заметку.

Сначала это выглядит очень удобно.

Например:

Собери из заметок папки Research черновик новой статьи и сохрани его в Drafts.

Или:

Создай заметку с результатами сегодняшнего исследования.

Но затем возникает другой сценарий.

Модель неправильно поняла задачу, решила «улучшить» существующий файл и перезаписала часть текста.

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

Поэтому я отношусь к write-доступу примерно как к доступу нового разработчика к репозиторию.

Работать можно.

Но хорошо бы видеть diff.

Как безопасно давать MCP доступ к Obsidian

Несколько ограничений резко уменьшают возможный ущерб.

1. Не подключать весь vault без необходимости

Если для задачи нужна только:

Projects/MyProject/

нет особого смысла давать модели доступ к:

Personal/
Finance/
Passwords/
Private/

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

2. Использовать read-only там, где запись не нужна

Большая часть моих сценариев вообще не требует изменения исходных заметок.

Поиск, анализ, сравнение и summarization прекрасно работают только с чтением.

Read-only должен быть дефолтом, а write-доступ — осознанно включаемой возможностью.

3. Хранить важные заметки в Git

Markdown для этого подходит идеально.

Если модель что-то изменила:

git diff

сразу показывает результат.

А неудачное изменение можно откатить.

4. Ограничивать разрешённые директории

Вместо одного глобального:

vault_write("*")

безопаснее определить область:

Drafts/**
AI/**
Projects/Current/**

и запретить изменения во всём остальном vault.

5. Использовать patch вместо полной перезаписи

vault_write прост, но довольно груб.

Если заметка занимает 500 строк, а модели нужно исправить один абзац, передавать ей возможность заменить весь файл необязательно.

Следующая логичная ступень для моего проекта — операции уровня patch:

было
 ↓
предлагаемый diff
 ↓
проверка
 ↓
применение

Такая модель мне кажется значительно здоровее, чем:

модель решила изменить файл
 ↓
файл изменился

AI хорошо ускоряет работу, но ускорение не должно означать потерю контроля над изменениями.

MCP и RAG — это одно и то же?

Нет.

И это один из вопросов, который довольно быстро возникает при разговоре о базе знаний и LLM.

Классическая схема RAG выглядит примерно так:

документы
   ↓
индексация
   ↓
embeddings / search
   ↓
релевантные фрагменты
   ↓
context
   ↓
LLM

Перед генерацией система сама ищет подходящие фрагменты и добавляет их в контекст.

С MCP схема другая:

LLM
 ↓
решает вызвать tool
 ↓
search
 ↓
получает результат
 ↓
решает прочитать файл
 ↓
read
 ↓
при необходимости вызывает следующий tool

То есть MCP в первую очередь описывает интерфейс взаимодействия модели с внешней системой.

RAG — механизм поиска и доставки релевантного контекста.

Они прекрасно могут работать вместе.

Например, MCP tool:

semantic_search

внутри может использовать embeddings и vector database.

Для моего Obsidian пока хватает обычного полнотекстового поиска и glob, но на большом хранилище semantic search становится вполне логичным следующим уровнем.

Поэтому вопрос обычно не «MCP или RAG».

Гораздо полезнее спросить:

Какие операции я хочу разрешить модели и каким способом каждая из них должна искать данные?

MCP или AI-плагин для Obsidian

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

AI-плагин может дать чат, поиск, summarization и генерацию прямо внутри интерфейса.

Я выбрал MCP по другой причине: мой центр работы находится не в Obsidian.

Сегодня это Cursor.

Завтра Claude.

Иногда ChatGPT.

Может появиться ещё один клиент.

Я не хочу строить отдельную интеграцию:

Obsidian → Cursor
Obsidian → Claude
Obsidian → ChatGPT
Obsidian → следующий клиент

Мне интереснее:

                Cursor
                  ↑
Obsidian → MCP ← Claude
                  ↑
                ChatGPT

В идеале меняется клиент, но интерфейс к данным остаётся тем же.

Это и есть одна из вещей, которые делают MCP интересным для меня как инженера: протокол позволяет разделить источник данных и конкретную LLM.

Какие сценарии оказались полезными на практике

Я начинал проект ради простого поиска заметок, но довольно быстро задачи стали сложнее.

Восстановить историю решения

Найди все заметки по проекту X, где упоминается Redis, и объясни, почему я в итоге выбрал PostgreSQL.

Очень полезный сценарий для решений, которые принимались несколько месяцев назад.

Собрать контекст проекта

Прочитай заметки в Projects/MyProject и составь краткое описание текущей архитектуры.

Можно быстро восстановить контекст после перерыва.

Найти незавершённые мысли

Найди заметки про MCP, в которых есть вопросы или TODO, и собери их в один список.

База знаний неожиданно превращается в источник задач.

Работать с daily notes

Найди все упоминания проекта за август и собери хронологию того, что происходило.

По отдельности daily notes плохо подходят для такой работы. Для модели собрать их вместе довольно естественно.

Подготавливать статьи

Найди мои заметки про vector search, сгруппируй идеи и предложи структуру статьи.

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

Что я понял после разработки собственного Obsidian MCP

Первоначально я думал, что пишу маленькую интеграцию.

Со временем понял, что меня гораздо больше интересует сама идея контекста.

Современная LLM знает огромное количество вещей о мире и практически ничего — о моей конкретной работе.

Она не знает, какое архитектурное решение команда приняла три месяца назад.

Не знает, какой эксперимент уже провалился.

Не знает, какие идеи я записал вчера.

Не знает, почему в проекте существует странное ограничение, которое снаружи выглядит бессмысленным.

Каждый новый разговор начинается почти с амнезии.

Мы пытаемся исправить это огромными context windows, RAG, памятью, MCP и десятком других подходов, но фундаментальная задача остаётся одной и той же:

дать модели правильный контекст в нужный момент.

Причём просто загрузить в prompt вообще всё — не решение.

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

Именно поэтому для меня такими важными оказались самые скучные части проекта:

search
glob
tree
read

Они не делают модель умнее.

Они позволяют ей самостоятельно разобраться, что именно нужно узнать перед ответом.

Личная база знаний постепенно становится инфраструктурой

Раньше я воспринимал Obsidian как хороший архив.

Записал мысль.

Через месяц нашёл.

Иногда связал с другой заметкой.

После появления LLM отношение начало меняться.

Если AI становится постоянной частью рабочего процесса, база накопленного контекста тоже перестаёт быть просто коллекцией Markdown-файлов.

В ней лежит история решений.

Контекст проектов.

Результаты исследований.

Ошибки.

Черновики.

То, что я когда-то уже понял и не хочу понимать заново.

В таком виде личная база знаний становится ещё одним слоем инженерной инфраструктуры.

Не памятью самой модели, а внешней памятью, к которой модель может обращаться.

Мне кажется, это гораздо интереснее идеи «AI, который знает всё».

Общие знания у современных моделей и так огромные.

Самая ценная информация часто находится не в интернете.

Она находится в наших репозиториях, документации, переписке, заметках и истории решений.

Главная задача следующего поколения AI-инструментов поэтому может оказаться не в том, чтобы сгенерировать ещё больше текста.

А в том, чтобы безопасно дать модели доступ к тому контексту, который уже существует.

Для себя я начал с самого простого варианта: обычной папки с Markdown-файлами и шести MCP tools.

Obsidian остался Obsidian.

LLM осталась LLM.

Зато между ними наконец почти исчез разработчик, который целый день нажимал Ctrl+C и Ctrl+V.

Исходный код моего MCP-сервера: https://github.com/tenqz/obsidian-agent

Документация Model Context Protocol: https://modelcontextprotocol.io/