💻 MCP-сервер - вже не wrapper для REST API

Коли MCP тільки з’явився, сервери часто будували як адаптери: загорнути REST-ендпойнти в tools - готово.

Тепер агенти через MCP можуть повторити виклик, використати застарілі дані чи запустити не ту операцію. Тому MCP-сервер - це інженерна межа між агентом і системою.

Ось чотири практики проєктування MCP-серверів із мого досвіду роботи над Anki MCP і Workstream Cockpit.

1. Ізолювати сервери, які працюють постійно. Для кількох локальних допоміжних інструментів вистачить stdio. А якщо MCP-сервер має працювати постійно, я особисто надаю перевагу Docker і Streamable HTTP. Контейнер відокремлює внутрішній стан MCP-сервера від середовища, яке запускає агента.

2. Не реалізовувати протокол самотужки. В основі Anki MCP - FastMCP з офіційного Python SDK. Для TypeScript є офіційний SDK, для Java - Spring AI MCP starters. Менше власного транспортного коду - більше уваги до логіки інструментів.

3. Проєктувати tools під сценарій, а не відтворювати CRUD-модель. Агенту корисніша одна завершена операція: перевірити, чи дані не застаріли, а залежності валідні, застосувати зміни та проконтролювати результат. У Workstream Cockpit expectedVersion захищає від запису поверх уже змінених даних. Що менше кроків оркеструє модель, то менше місць для помилки.

4. Розділяти читання, запис і небезпечні операції. У режимі лише для читання інструментів запису й видалення не має бути навіть у tools/list; права все одно перевіряються на кожному виклику. Для зміни з невисоким ризиком мінімальний запобіжник - confirmed: true. Для критичних змін краще працює схема: preview → короткоживучий токен, прив’язаний до конкретної операції → mutation. У мене модель з такою схемою перепитувала, якщо вибір був неочевидним.

Секрети надходять із конфігурації, захищеного сховища або через OAuth - і ніколи не передаються через tools.

Якщо MCP лише повторює REST API, інтерфейсу для агента ще немає. Це просто Swagger, який навчився говорити JSON-RPC.

---
🌱 Keep calm and grow | 💬 Обговорити 1-на-1