Comments 23
Интересно, спасибо за детальную инструкцию.
Вопрос - а в чем преимущество mcp, по сравнению с прямым доступом агента к файлами?
Скорее всего для повышения качества и минимизации потребления токенов. Но есть cli https://obsidian.md/cli и даже eval и доступ js объектам есть доступ.
MCP это протокол разработанный специально для ИИ-моделей, он упрощает взаимодействие с данными и может снабжать каждый запрос дополнительными инструкциями
Тоже интересно, почему бы не хранить этот набор md-файлов не отдельно в Obsidian, а прямо в репозитории.
Скорее всего для повышения качества и минимизации потребления токенов
Насколько я понимаю, Claude не читает весь код при каждом запросе. Он читает отдельные файлы, которые необходимы для контекста конкретного запроса. Соответственно, чтение файлов напрямую или из Obsidian MPC различается только протоколом. Поправьте меня, если я ошибаюсь.
Поддерживаю. Мало того подключение связки obsidian -mcp и локальными ключами api надо каждому участники подпрыгивать, раздувается зоопарк инструментов, к эффект тот же - текстовые файлике а гите
Если проект ограничивается одной папкой, то это действительно не нужно. Но если проект больше, разработчиков несколько, то этот вариант удобнее, так как у каждого будет одна общая база знаний и одинаковый набор промптов.
Это позволит не плодить инструкции и не воссоздавать контекст в каждом отдельном модуле вашего сервиса.
В целом и в этом случае можно создать отдельную папку и ссылаться на неё, но Obsidian в этом случае это просто удобный инструмент, который настраивается один раз и работает одинаково в каждой части проекта.
Но обязательно нужно всё очень тщательно оттестировать, потому что mcp сам по себе требует довольно много токенов от модели, насколько я понимаю
Очень крутой гайд, как раз для моего диплома
А почему просто не дать клоду доступ к md файлам на прямую? Зачем лишняя прослойка в виде mcp?
Чуть выше ответил. Если коротко: вам не нужен mcp, если ваш проект ограничивается одной папкой, в противном случае - это удобнее, чем создавать разрозненные файлы документации в каждой части большого проекта
Да незачем походу. Единственный плюс который можно придумать - это +- удобный кросплатформенный клиент для md файлов. А так между папочками агенты и сами ходить умеют.
(у себя пользуем Azure инфраструктуру и весь контекст лежит в AzureDevops wiki. Она как раз md.)
Очень много слышал тезисов, что такие вещи помогают экономить на расходы токенов. Но не понимаю самой механики экономии. За счет чего она достигается ? По сути агенту сразу в промпт каждый мы грузим инструкцию и явно не контролируем что он будет забирать себк в контекст. Вот если мы явно скажем действуй в рамках такого домена, он не будет лезть в сторону, а в обсидиан (в данном примере) нам необходимо контролировать связи между документами, чтобы делая уловную корзину из за кривой связи агент не начал выкачивать в контекст то как устроены каталоги
Статья хорошая, я как раз ищу сейчас как грамотно использовать обсидиан в жизни, но хотелось бы больше понять механику экономии, илм может подкрепление статьи какими то исследованиями в этой области, а то слово "экономия" выглядит просто как кликбейт)
Экономия достигается за счет структурирования файлов в Obsidian. Для этого нужно в промптах к каждому разделу вики грамотно указать каким образом с ним работать, а так же время от времени просить модель разбивать крупные файлы.
Таким образом модель будет изучать проект по кусочкам, отбирая только необходимый для задачи контекст.
Модель сама будет формировать грамотную структуру Obsidian при хорошем промпте, но надо не забывать периодически контролировать её работу
Если задача — «прочитай мою почту, заведи тикет в Jira, отправь сообщение в Slack», то либо ты пишешь свои HTTP-обёртки и даёшь их модели как тулзы (фактически переизобретая MCP), либо берёшь готовый MCP-сервер.
То вот в этом случае да MCP хороший вариант. Во всех случаях агентный клауд (из Claude Code, не из браузера) даже может подключиться по ssh и всё тебе на сервере настроить без MCP и чего-то бы то не было ещё. Создаёшь для него отдельный публичный ключ с отдельным паролем и говоришь что делать и онт делает. При этом даже токенов меньше тратится т.к он не тратит время на объяснение тебе своих действий, а просто делает. Если же он убил впс (такое возможно, учитывайте это), то можно просто нажать кнопку reinstall у хостера или выполнять все в контейнере.
Чего бы я не стал делать, так это давать ему доступ к проду или важным личным ресурсам типа своего тг канала или джиры, вот в таких случаях MCP хорошо, если правильно настроен и защищает инфру от обезьянки с гранатой.
Написал “semantic” - пиши какая модель для эмбеддингов.
никто не ответил, пришлось самому в issue идти: https://github.com/aaronsb/obsidian-mcp-plugin/issues/62
The “semantic” in the plugin name refers to the semantic MCP interface design - organizing tools by intent (vault, view, edit, graph) rather than exposing raw operations. It doesn’t (currently) imply vector embeddings.
Семантика 80 уровня.
Разработка с Obsidian + Claude. Практический гайд