Комментарии 4
Вы сами то читали статьи на которые ссылаетесь ? Для MCP servers уже давно есть SDK под разные языки, в том числе и под Python. Ваш пример это что то похожее не MCP, но это не MCP server, попробуйте подключиться к вашему серверу с использованием MCP Inspector и сделать что нибудь.
Спасибо за комментарий! Вы правы, что существуют официальные Python SDK и MCP Inspector, но в статье мне было важно не повторить документацию, а показать основную идею протокола на простом, наглядном примере — без лишней обвязки и магии. Суть в том, чтобы вынести логику взаимодействия с внешним миром из каждого агента в отдельный сервер. Тогда «рой» агентов сможет использовать одни и те же инструменты без дублирования, используя стандартные LLM‑механизмы вроде function calling.
Важно помнить, что сам протокол изначально создавался под локальные сценарии — прежде всего для интеграции с Claude Desktop. Прямая цитата из документации:
«build a simple MCP weather server and connect it to a host, Claude for Desktop»То есть о масштабируемой сетевой архитектуре речи тогда ещё не шло. Это, конечно, сдерживает развитие MCP, но сообщество активно его пушит вперёд. А то, что к инициативе подключились Google и OpenAI, даёт надежду на ускорение вразвитие протокола.
А в чём разница двух реализаций описанных в статье?
С функциональной точки зрения оба агента работают ровно одинаково — они подключаются к одному и тому же серверу, запрашивают у него список доступных инструментов и вызывают их по HTTP. Разница лишь в том, как мы реализуем клиентскую логику:
Нативная реализация (FastAPI + OpenAI‑клиент): всё вручную, сами вызываем нужные HTTP‑методы и обновляем контекст.
Фреймворк
openai-agents: весь цикл работы с инструментами происходит «из коробки».
Но в обоих случаях сервер остаётся один и тот же. То есть, независимо от того, используем ли мы «чистый» код или готовый фреймворк, все агенты переиспользуют единый сервер и единый набор инструментов, не дублируя реализацию.
MCP своими руками