Коли 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