← Все статьи

От инженера ПО к AI-инженеру, часть 5: масштабирование инструментов через MCP

Model Context Protocol — каталог инструментов для приложений ИИ: сервер, клиент, JSON-RPC и пример PayIQ на FastMCP.

От инженера ПО к AI-инженеру, часть 5: масштабирование инструментов через MCP
Содержание

Коротко

Пятая часть серии Bjorn van der Laan про переход к AI-инженерии: вместо того чтобы каждое приложение писало свои инструменты с нуля, команды выносят их в переиспользуемый каталог через MCP (Model Context Protocol, протокол контекста модели). Сервер публикует инструменты, клиент забирает каталог и отдаёт модели; вызовы идут по JSON-RPC 2.0 поверх streamable HTTP или stdio.

Что произошло

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

Транспорт:

  • streamable HTTP — сервер за URL, удобно для общих деплоев;
  • stdio — клиент поднимает сервер как subprocess и общается через stdin/stdout.

В примере PayIQ автор оборачивает calculate_refund_cost и search_payments_knowledge_base в FastMCP (langchain_mcp_adapters), стартует python -m app.mcp_server и через curl инициализирует сессию (initializeMcp-Session-Idtools/list). Структура каталога совпадает с локальными tools из части 3.

Клиент на LangChain (MultiServerMCPClient) подтягивает tools, биндит их к модели (Claude Sonnet в примере). На вопрос про возврат €480 модель сначала вызывает поиск по базе знаний, затем калькулятор комиссий — цепочка из двух tool calls. Автор намекает: нужен цикл вызовов до финального ответа — это уже шаг к агентному поведению.

Почему это важно

В компании десятки интеграций — git, тикеты, мониторинг. Дублировать обёртки в каждом чат-боте дорого. MCP — попытка стандартизировать «API инструментов для моделей», как REST когда-то стандартизировал HTTP-сервисы. Для AI-инженера это та же роль, что у backend-разработчика: и свой сервер, и чужие каталоги.

На практике

  1. Выделите инструменты с чёткими схемами параметров — модель читает описания буквально.
  2. Поднимите MCP-сервер отдельным процессом; для локальной разработки удобен stdio, для команды — HTTP с сессиями.
  3. В клиенте держите map tool_name → handler и после ответа модели выполняйте вызовы в цикле, пока не будет финального текста.
  4. Не смешивайте «каталог для модели» и бизнес-авторизацию: кто может вызывать refund или читать KB — решает сервер, не промпт.
  5. Код серии — в репозитории-приложении.

Итог

MCP переносит инструменты ИИ из «каждый проект с нуля» в переиспользуемую инфраструктуру. Следующий логичный шаг после каталога — цикл tool calls, то есть полноценный агент; серия обещает разобрать это в следующей части.