Неделя 7 — MCP (даём агенту собственные инструменты стандартным способом)

Часть моего пути по прокачке навыков автоматизации в условиях, когда отрасль движется в сторону ИИ. Эта неделя посвящена Model Context Protocol (MCP) — вместо вставки данных в промпт LLM получает небольшой набор инструментов и сама решает, какие из них вызвать и в каком порядке, чтобы ответить на вопрос.

Почему эта неделя важна: жёсткое зашивание данных в промпт не масштабируется дальше демо. MCP — это становящийся стандарт подхода «вот ваши инструменты и источники данных — вперёд»; именно он позволяет агенту подключиться к живой системе, а не к снапшоту.

Архитектура

[client.py asks a question]
            |
            v
[Claude sees 3 tool definitions — no invoice data in the prompt]
            |  decides which tools to call, with what arguments
            v
[MCP server (server.py): list_invoices / get_invoice / get_purchase_order]
            |  returns live data over stdio
            v
[Claude reasons over the results and answers]

Преемственность: на неделе 2 извлекали счёт из документа. Неделя 6 решала, что делать с исключением счетом, используя данные, которые у бота уже были на руках. На этой неделе сами данные живут внутри MCP-сервера — агент сам получает нужные ему факты, а не берёт уже заготовленные. Соедините это со защищённой политикой службой решений из недели 6 — и получите Portfolio Project #4 из дорожной карты: агент, который и сам ищет факты, и передаёт решение на проверку аудируемому слою правил.

Related MCP server: Invoice MCP Server

Что здесь

1. Запуск

python -m venv .venv
.venv\Scripts\Activate.ps1
pip install -r requirements.txt
# copy .env.example to .env and paste your key

python src/client.py

client.py сам запускает server.py через stdio (именно так MCP обычно работает с локальными инструментами — здесь нет HTTP-порта для управления, в отличие от недели 6). Смотрите, как выводят строки [MCP tool call: ...] в тот момент, когда Claude решает, какие данные ему нужно найти.

Запустите юнит-тесты для логики инструментов (API-ключ не требуется):

pytest

2. Ключевая идея дизайна: инструменты + данные поверх стандартного протокола

До MCP «выдать модели инструмент» означало вручную катaть JSON-схему и диспетчер на if/elif для каждого проекта. MCP это стандартизирует: server.py объявляет инструменты один раз через @mcp.tool(), и любой MCP-совместимый клиент — client.py из этого репозитория, Claude Desktop, агент другой команды — может обнаружить их и вызывать таким же способом. Именно в этом суть «подключения агентов к реальным инструментам»: разработчик инструмента и агент не обязаны быть одним и тем же человеком.

3. Что я понял / что готово для продакшена, а что нет

• MCP разводит того, кто владеет данными, и того, кто о данных рассуждает — серверу не важно и он не знает, какая LLM его вызывает.

• Выбор модели тоже здесь важен: это оркестрация (выбор необходимого инструмента), а не сложные рассуждения, поэтому нужна дешёвая и быстрая модель (claude-haiku-4-5) — рассуждения уровня Opus оставьте решениям, которые происходят на неделе 6.

• Не ready для production: «ERP» — это словарь в памяти, у сервера нет аутентификации, и референ нет настоящего MCP-ресурса (только инструменты) — в продакшен-версии счета, вероятно, выбрали is бы как MCP ресурсы. (На неделе 8+.)

Мой стек

Python · MCP (official Python SDK) · Claude (claude-haiku-4-5 для работы с инструментами) · Anthropic SDK · pytest