[📌 Часть 1/2] — 27 июля 2026 г. в 13:00:43.984
[📌 Часть 1/2] MCP vs Function Calling: Протокол, который убивает спагетти-код инструментов в AI-архитектурах \n\n Когда агенты перестают быть простыми цепочками промптов и превращаются в сложные системы с доступом к базам данных, API внешних сервисов и файловой системе, архитектура интеграций ломается под весом проприетарных схем. Классический Function Calling привязывает инструменты к конкретному провайдеру модели: вы пишете openai_tools.py, дублируете логику для Anthropic, адаптируете JSON-схемы под Ollama/LM Studio и в итоге получаете монолитный оркестратор, который невозможно масштабировать. Смена модели тянет за собой рефакторинг всего слоя инструментов. Model Context Protocol (MCP) [https://modelcontextprotocol.io/] меняет парадигму: это не библиотека, а открытый стандарт взаимодействия между LLM-клиентами и источниками данных/инструментами. MCP абстрагирует транспорт и семантику, превращая инструменты в независимые микросервисы, которые объявляют свои возможности через унифицированные JSON-RPC эндпоинты. Вы не хардкодите функции в код приложения — вы подключаете MCP-серверы, которые могут быть написаны на любом языке и изолированы в отдельных контейнерах или процессах. Главное архитектурное преимущество — слабая связность. Ваш оркестратор (LangGraph, Semantic Kernel, кастомный агент) общается с абстрактным протоколом. Список инструментов динамически подтягивается через tools/list, параметры валидируются на стороне MCP-сервера, а исполнение изолировано. Если вчера вы использовали Anthropic, а сегодня переходите на локальный Qwen2.5 с поддержкой MCP, код инструментов не меняется. Вы меняете только клиентский коннектор к модели.