Нотатки про MCP-сервери

Я побудував кілька MCP-серверів — два для AI-visibility платформи й один над контент-конвеєром. Протокол — проста частина. Дисципліна — не перебудовувати свій продукт усередині сервера.

Один інструмент — одна задача

Інструмент має робити одну річ, і його опис має точно казати, яку. Модель читає опис і майже нічого більше, перш ніж вирішити тебе викликати, тож розмитість тут повертається неправильними викликами.

export const tool = {
  name: 'get_run',
  description: 'Fetch one agent run by id, with its steps and trace.',
  inputSchema: { type: 'object', properties: { id: { type: 'string' } }, required: ['id'] },
};

Читання дешеве, запис явний

Тримай читання й запис окремо та познач їх. Читання може виконуватися саме по собі. Усе, що витрачає гроші чи змінює стан, — це запис: дай йому окремий інструмент і познач у схемі, а не в коментарі, якого модель не прочитає.

Тип	Приклад	Підтвердження
Читання	get_run	немає
Запис	cancel_run	потрібне

Проксі, а не друга реалізація

Поширена помилка — перебудувати свою логіку всередині сервера. Той, якому я довіряю, — тонкий проксі над реальним сервісом: ті самі ендпоінти, ті самі довговічні запуски, та сама авторизація й стеля вартості. Клієнт отримує можливість без другої копії продукту, яку треба синхронізувати. Контроль доступу й усе, що витрачає гроші, лишаються на сервісі, де вони вже живуть.

Наостанок

Протокол малий за задумом. Робота — чесно відкрити систему, яку ти вже запускаєш, і лишити цю систему єдиним місцем, де живе логіка.