Обробка помилок MCP-сервера: чого я навчився
Я думав, що все готово, коли мій MCP-сервер запустився вперше. Він повернув список інструментів. Він викликав інструмент. Я відчув успіх.
Я помилявся.
Запуск MCP-сервера у продакшені навчив мене, що туторіали зосереджені на «щасливому шляху» (happy path). Вони ігнорують те, що стається, коли щось ламається. Ось чого я навчився, створюючи сервер для своєї бази знань обсягом 1800 годин.
Завжди повертайте контент для порожніх результатів Більшість клієнтів зависають, коли отримують порожню відповідь. Якщо ваш пошук нічого не знаходить, не повертайте «нічого». Поверніть текстове повідомлення. Поясніть користувачеві, чому немає результатів і скільки елементів є у вашій базі даних.
Керуйте повільним початком з'єднання Я хощу на безкоштовному тарифі, який переходить у режим сну. Коли він прокидається, це займає 15 секунд. Багато MCP-клієнтів завершують роботу за тайм-аутом ще до цього. • Надсилайте заголовки на ранніх етапах, щоб підтримувати з'єднання активним. • Встановіть жорсткі ліміти на розмір відповіді. Обрізайте великі результати, щоб не перевищити ліміти тайм-ауту.
Припиніть вручну створювати JSON Одна неекранована подвійна лапка в заголовку зламала всю мою JSON-відповідь. Клієнт відключився без помилки. Використовуйте такі фреймворки, як Jackson, для серіалізації. Дозвольте бібліотеці керувати екрануванням за вас.
Очікуйте на невідповідність методів автентифікації Різні клієнти по-різному обробляють API-ключі. Дехто використовує заголовки. Дехто — параметри запиту. Дехто не використовує нічого з цього. • Підтримуйте кілька способів передачі ключів. • Завжди повертайте коректне тіло помилки у форматі JSON, якщо автентифікація не вдалася.
Встановлюйте явний Content-Length Деякі клієнти мають проблеми з chunked encoding. Якщо ваші відповіді обрізаються, припиніть використовувати стиснення. Попередньо обчислюйте розмір вашої відповіді та явно встановлюйте заголовок Content-Length.
Переваги: • Приватність: ШІ отримує лише релевантні фрагменти. • Сумісність: Сервер працює з різними клієнтами. • Простота: Мій сервер складається лише зі 150 рядків коду.
Недоліки: • Молода екосистема: У документації бракує багатьох граничних випадків. • Хостинг: Ви повинні самостійно керувати своїми ендпоінтами та «холодними стартами». • Еволюція: Протокол часто змінюється.
MCP перетворив мої непотрібні нотатки на корисний інструмент. Він робить мої дані доступними, щоб ШІ міг виконувати основну роботу.
Ви створювали MCP-сервер? З якими помилками ви стикалися? Пишіть у коментарях.
Додаткова спільнота для навчання: https://t.me/GyaanSetuAi