Захист клієнтів Model Context Protocol: обмежена пагінація та перевірка конформності
Пакет dart_mcp впровадив безпечну пагінацію з лімітом у 64 сторінки, щоб уникнути зациклення через некоректні сервери Model Context Protocol. Оновлення також додає щотижневі перевірки на конформність специфікації та робочий клієнтський приклад для streamable HTTP.
Вплив: Середній
Чому це важливо
Ви зможете запобігти зависанню агентів, обмеживши пагінацію при опитуванні MCP-серверів та налаштувавши автоматичні тести конформності.
TL;DR
- 01Встановлюйте явний ліміт сторінок (наприклад, 64) під час вибірки списків інструментів через курсори MCP.
- 02Використовуйте двосторонній контроль бейзлайну для нестабільних тестових сьютів у CI.
- 03Повертайте 400 Bad Request замість 415, якщо заголовки запиту MCP не проходять валідацію.
Ключові факти
- Ліміт пагінації за замовчуванням
- 64 сторінки
- Тригер перевірки конформності в CI
- Щотижня, вручну та при змінах у пакеті
- Код помилки валідації заголовків
- 400 Bad Request
Захисна пагінація для клієнтів протоколу
Опитування MCP-сервера через стандартні виклики списків вимагає пагінації каталогу інструментів і ресурсів. Якщо клієнт не має обмежень, нескінченна генерація токена nextCursor стороннім сервером призводить до зависання процесу. У PR #682 бібліотека dart_mcp впровадила допоміжні стрімові методи (listAllTools, listAllResources, listAllResourceTemplates, listAllPrompts) із лімітом у 64 сторінки за замовчуванням. Безлімітний режим доступний лише за явної передачі null.
Щотижневий моніторинг конформності
У PR #675 додано регулярний запуск офіційного тест-сьюту конформності MCP у GitHub Actions. Оскільки тестовий пакет протоколу ще в альфі, пайплайн використовує continue-on-error у поєднанні з контрольним списком (baseline). Збірка зупиняється у двох випадках: 1. Падає сценарій, якого немає у списку винятків. 2. Сценарій зі списку відомих помилок несподівано проходить успішно.
Такий підхід захищає кодову базу від непомітного розсинхрону зі специфікацією.
Виправлення граничних випадків протоколу
Окремі PR усунули розбіжності на рівні серіалізації: PR #685 адаптував парсинг SamplingMessage.content і CreateMessageResult.content, дозволивши приймати як окремі блоки, так і масиви. PR #684 змінив код відповіді при невідповідності заголовків із 415 на 400 Bad Request відповідно до схеми HeaderMismatch.
Спробуй за 2 хвилини
final toolsStream = client.listAllTools(maxPages: 64);
await for (final tool in toolsStream) {
print('Discovered tool: ${tool.name}');
}dart
✓ Коли використовувати
- Під час розробки або використання клієнтських бібліотек для Model Context Protocol.
- При підключенні до зовнішніх MCP-серверів з динамічними каталогами ресурсів та інструментів.
✕ Коли НЕ варто
- Для простих MCP-серверів із фіксованим невеликим набором утиліт без підтримки пагінації.
- Під час взаємодії з REST API, які не використовують протокол Model Context Protocol.
Що зробити сьогодні
- Перевірте клієнтський код MCP на наявність нескінченних циклів обробки токена nextCursor.
- Додайте обмеження кількості сторінок (наприклад, 64) у всі виклики списків MCP.
- Підключіть сьют перевірки конформності MCP до свого CI з фіксацією очікуваних відхилень.
Джерела