Продукт · Управління MCP
Керуйте MCP — каталогізуйте кожен інструмент, з’єднайте, хто чим користується
Модуль V, «Можливості». Клієнт MCP виконує інтроспекцію tools/list і resources/list кожного сервера й заносить їх до внутрішнього реєстру, тож ви отримуєте версіонований каталог серверів, навичок та інструментів — плюс граф зв’язків, який показує, який агент яким інструментом користується. Керована конфігурація посилається на ваші секрети за посиланням; сирі значення секретів ніколи не потрапляють до каталогу.
У продукті
Консоль можливостей
Справжній знімок екрана, дані для прикладу. Вкладки для серверів, навичок, інструментів, графа зв’язків можливостей і керованих конфігурацій. Стан підключення виводиться з реальних сигналів; затверджені записи несуть хеш вмісту, а за наявності ключа підпису — підпис Ed25519.
Чим ви керуєте
Реєстр для кожного інструмента, до якого можуть звертатися ваші агенти
Клієнт MCP працює через stdio та Streamable HTTP, виконує інтроспекцію кожного сервера й фіксує те, що знаходить, — тож каталог відображає те, що сервери справді надають, а не те, що стверджує таблиця.
Каталог на основі інтроспекції
Клієнт викликає tools/list і resources/list через stdio або Streamable HTTP (SSE — застарілий стандарт) і записує результат до внутрішнього реєстру. Ви отримуєте версіонований каталог серверів MCP, навичок та інструментів, де стан підключення виводиться з реальних сигналів, а не підтримується вручну.
Граф зв’язків можливостей
Бачте, який агент з’єднано з яким інструментом, — граф «хто чим користується» в самому серці консолі. Це карта використання; вона відрізняється від карти доступу для читання/читання-запису, яка є окремою поверхнею й відповідає на інше питання.
Секрети за посиланням, ніколи в сирому вигляді
Керована конфігурація MCP посилається на ваші секрети за посиланням (secret_refs). Сирі значення секретів ніколи не зберігаються в каталозі й не читаються з нього — конфігурація вказує на секрет, але не містить його.
Анотації оголошуються, а не приймаються на віру
Сервери MCP можуть оголошувати на інструменті read_only_hint або destructive_hint. Ми подаємо їх як оголошений, ненадійний сигнал від сервера — ніколи як авторитетний знак безпеки. Сприймайте їх як підказку для перевірки, а не як істину про безпеку.
Що є реальним
Каталог, граф і керована конфігурація вже працюють; повна готовність до MCP-RC у процесі
Ми точні щодо того, що контракт гарантує сьогодні, а чого ні:
- Вже працює (стабільний контракт v1): клієнт MCP через stdio та Streamable HTTP, інтроспекція tools/list і resources/list до внутрішнього реєстру, каталог серверів / навичок / інструментів, граф зв’язків можливостей і керована конфігурація, що посилається на секрети за посиланням. Стан підключення виводиться з реальних сигналів.
- Затвердження та цілісність: затверджені записи каталогу несуть хеш вмісту й необов’язковий підпис Ed25519. Якщо ключ підпису не налаштовано, запис відображається як «затверджений, але без підпису» — ми кажемо це прямо, а не натякаємо на підпис, якого там немає.
- Не повна відповідність специфікації: готовність до MCP RC (специфікація 2026-07-28) у процесі, а кілька змін специфікації ще не реалізовано — ми не заявляємо про повну чи актуальну відповідність специфікації MCP. Публічний реєстр MCP перебуває у попередньому перегляді й нині відхиляє приватні сервери; приватний субреєстр є в дорожній карті.
- Підхід: спершу читання, за замовчуванням — спостережувальний. Каталог і граф описують, що надають ваші сервери та як з’єднано інструменти; вони нічого не переналаштовують і не приводять у дію без вашого відома.
Управління MCP — запитання
Чи свідчать анотації read_only_hint / destructive_hint про те, що інструмент безпечний?
Ні. Ці анотації оголошує сам сервер MCP, тож вони є ненадійним сигналом — сервер може стверджувати будь-що. Ми подаємо їх у каталозі як оголошену підказку, що допомагає вирішити, що варто перевірити, але ніколи як авторитетний знак безпеки. Не сприймайте анотацію «лише читання» як доказ того, що інструмент не може писати.
Чим граф зв’язків відрізняється від карти доступу?
Граф зв’язків можливостей відповідає на питання «який агент яким інструментом користується» — це карта використання з’єднань у цій консолі. Карта доступу для читання/читання-запису є окремою поверхнею продукту й відповідає на питання «який рівень доступу має ідентичність до ресурсу». Вони свідомо розмежовані; ми не плутаємо одне з іншим.
Чи зберігаються мої секрети в каталозі MCP?
Ні. Керована конфігурація MCP посилається на секрети за посиланням (secret_refs) — конфігурація вказує на секрет, але не містить його сирого значення. Каталог ніколи не зберігає й не читає сирий секретний матеріал.
Чи повністю Olivares відповідає чинній специфікації MCP?
Ще ні, і ми не заявлятимемо про це, доки не випустимо. Робочий клієнт MCP — це стабільний контракт v1 через stdio та Streamable HTTP (SSE — застарілий стандарт), але готовність до MCP RC (специфікація 2026-07-28) усе ще в процесі, а кілька змін не реалізовано. Публічний реєстр MCP перебуває у попередньому перегляді й відхиляє приватні сервери; приватний субреєстр є в дорожній карті.
Каталогізуйте свій парк MCP і керуйте ним
Розгорніть Olivares на власній інфраструктурі, виконайте інтроспекцію своїх серверів MCP до версіонованого каталогу, побачте, хто з’єднаний з яким інструментом, і тримайте секрети за посиланням — ніколи в сирому вигляді.