MCP (Model Context Protocol)

Коротко: Відкритий протокол, що дає змогу ШІ на кшталт Claude звертатися до зовнішніх інструментів і джерел даних (файли, API, застосунки) через єдиний канал, без потреби писати окрему інтеграцію для кожного застосунку.

Докладніше: MCP-сервер пропонує «інструменти» (функції, що викликаються) через стандартизований інтерфейс — транспортом можуть бути, наприклад, stdio, SSE або Streamable HTTP. Клієнт (тут Claude Code) підключається, отримує список доступних інструментів і потім викликає їх, як вбудовані.

Наш контекст: Ваше сховище Obsidian підключене через MCP — плагін «MCP Connector» (istefox) запускає в Obsidian локальний MCP-сервер (http://127.0.0.1:27200/mcp), який ми зареєстрували в Claude Code командою claude mcp add --transport http і автентифікували за допомогою bearer-токена.

Подробиці

Три основні будівельні блоки

Три основні блоки, які MCP-сервер може запропонувати клієнту на кшталт Claude: інструменти (функції, що викликаються, із визначеними параметрами, наприклад «прочитати цей файл» чи «надіслати це повідомлення»), ресурси (дані, що читаються, такі як файли чи записи бази даних, які клієнт може отримати за потреби, зазвичай без побічних ефектів) і промпти (наперед визначені, повторно використовувані шаблони запитів, що їх надає сервер, щоб користувачам не доводилося щоразу заново формулювати типові запити). На практиці інструменти на сьогодні використовуються безперечно найчастіше, бо дають моделі найбільшу здатність діяти — ресурси й промпти мають радше допоміжний характер.

Навіщо відкритий стандарт

Вирішальна перевага MCP як відкритого стандарту: без нього кожному ШІ-застосунку знадобилася б власна індивідуальна інтеграція для кожного зовнішнього застосунку (одна для Obsidian, одна для Slack, одна для GitHub, …) — з MCP один сервер, наданий спільнотою відповідного застосунку, може використовуватися БУДЬ-ЯКИМ клієнтом із підтримкою MCP, без потреби для постачальника клієнта самому писати цю інтеграцію. Це порівнянне з різницею між фірмовими зарядними кабелями та єдиним стандартом USB — до такого стандарту кожному виробнику доводилося постачати свій кабель для кожного пристрою; після нього практично для всього вистачає одного формату кабелю.

Типи з’єднання (транспорти)

Транспорт визначає, ЯК клієнт і сервер фактично обмінюються даними. stdio (стандартне введення/виведення) підходить для локально запущених серверів, які клієнт сам запускає як підпроцес — просто, але прив’язано до однієї машини. SSE (server-sent events) і Streamable HTTP, навпаки, допускають підключення до віддалено працюючих серверів через мережу, зокрема автентифікацію (наприклад, за допомогою bearer-токена) — зручно, коли MCP-сервер працює не на тому самому пристрої, що й клієнт, а, наприклад, усередині Obsidian як локально запущена служба, доступна по HTTP.

Аспекти безпеки

Оскільки MCP-сервер потенційно дає клієнту широкі можливості (доступ до файлів, доступ до мережі, виконання дій у зовнішніх застосунках), питання про те, ЯКІ сервери ви підключаєте з ЯКИМИ правами, важливе для безпеки — шкідливий або скомпрометований MCP-сервер теоретично міг би вивести дані назовні або запустити небажані дії. Сумлінні MCP-клієнти тому зазвичай показують, які інструменти пропонує щойно підключений сервер, і дозволяють користувачеві явно підтверджувати окремі потенційно ризиковані дії (наприклад, видалення файлів), замість того щоб наосліп давати моделі повну свободу.

Походження

MCP було опубліковано Anthropic як відкритий стандарт з явною метою зменшити фрагментацію інтеграцій ШІ-інструментів — подібно до того, як Language Server Protocol (LSP) раніше уніфікував підключення підтримки мов програмування до різних редакторів коду, замість того щоб кожному редактору була потрібна своя реалізація для кожної мови.

Див. також: Streamable HTTP, Bearer-токен, Сховище Obsidian, Протокол