Все инструменты, написанные до сих пор, теряли данные сразу. Сервер столовой из модуля 2 записывал бронь в словарь, кэш координат из модуля 6 хранился в переменной, и стоило серверу остановиться, как всё это исчезало без следа. Для расчётов и справок этого достаточно. Для заявок, заказов и записей — нет: их придётся хранить по-настоящему.
В этом модуле у сервера появляется база данных. Она решает главную проблему — данные переживают перезапуск и видны всем клиентам сразу, — но приносит с собой три новые. Данные теперь можно испортить, причём необратимо. К ним обращаются несколько клиентов одновременно, и это нужно учитывать. И самое неприятное: запросы к базе теперь собирает не человек за клавиатурой, а модель, которой кто-то диктует текст. Аргумент инструмента, попавший в SQL-запрос неаккуратно, стирает таблицу целиком — и мы покажем это на живом опыте, а не на словах.
Базу берём самую простую из возможных — SQLite. Это один файл на диске и модуль sqlite3, встроенный в Python: ничего устанавливать не нужно, отдельный сервер запускать не нужно, и весь модуль использует то же окружение, что и предыдущие.
Три темы в модуле сознательно не рассматриваются. Проверку аргументов средствами Pydantic и правила хороших сообщений об ошибках разобрал модуль 7, и здесь они применяются в готовом виде. Секреты, права доступа, лимиты и журналирование как отдельную тему безопасности разбирает модуль 9. Инъекцию через данные, когда вредная инструкция попадает к модели в тексте документа, — тоже модуль 9. Здесь рассматривается одно: как устроен MCP-сервер, у которого есть состояние, и как не дать модели его разрушить.