Как подключить внешние инструменты к ИИ-агенту: разбираем MCP-сервер на практике

Разработчик из команды 30-дневного челленджа по агентному ИИ делится опытом настройки MCP-сервера — протокола, который позволяет языковым моделям обращаться к внешним инструментам. Разбираем идею, код и скрытые подводные камни.

MCP — это розетка для ИИ-агентов: воткнул инструмент, и модель умеет считать то, чего раньше не умела. Но между «воткнуть» и «работает» — пропасть из нюансов.

Зачем вообще MCP?

Model Context Protocol — стандарт, который Anthropic продвигает с конца 2024 года. Суть простая: вместо того чтобы каждый раз хардкодить возможности в промпт или файнтюнить модель, вы поднимаете отдельный сервер с инструментами. Любой MCP-совместимый ИИ-клиент — будь то Claude Desktop, Cursor, ваш собственный бот на LangGraph — подключается к этому серверу и «видит» доступные функции.

По сути, это клиент-серверная архитектура для функционального вызова (function calling), только стандартизированная. Модель не знает заранее, какие инструменты есть на сервере — она запрашивает список, получает описания и решает, когда и чем воспользоваться.

Идея не новая (OpenAI Function Calling, LangChain Tools — всё из той же оперы), но MCP пытается стать универсальным разъёмом. Как USB для периферии: один раз написал драйвер — работает везде.

Что пошло не так у автора оригинала

Kasi Yaswanth, автор 30-дневного челленджа по агентному ИИ на dev.to, рассказывает, что их команда столкнулась с «конверсационной амнезией» у чатбота поддержки на LangGraph. Бот не помнил контекст между сообщениями, и пользователи повторяли одно и то же снова и снова. Проблему автор связывает с отсутствием централизованного сервера инструментов.

Здесь стоит сделать оговорку: потеря контекста в диалоге — это, как правило, проблема управления историей сообщений, а не отсутствия MCP. Сервер инструментов не хранит состояние разговора; он лишь предоставляет функции. Возможно, реальный случай был сложнее, но в статье эта связь выглядит натянутой.

Разбор примера: анализ тональности

Автор предлагает реализовать простой инструмент — анализатор настроения текста. Вот что он демонстрирует:

class SentimentAnalysisTool(Tool, MCPTool):
    def __init__(self):
        super().__init__()
        self.name = "SentimentAnalysis"
        self.description = "Analyzes the sentiment of the input text"

    def execute(self, input_text):
        if "love" in input_text or "great" in input_text:
            return "Positive"
        elif "hate" in input_text or "bad" in input_text:
            return "Negative"
        else:
            return "Neutral"

Тут стоит остановиться. «Анализ тональности» — это поиск двух слов в строке? «I don't love this at all» вернёт «Positive», хотя текст явно негативный. «Bad» сработает для «not bad» как негатив. Понятно, что это учебный пример, но даже в демонстрации полезно показать хотя бы вызов библиотеки (TextBlob, transformers, что угодно), чтобы читатель не унёс домой идею, будто in — это NLP.

Сервер на Flask

Далее автор поднимает REST-сервер на Flask и регистрирует инструмент:

app = Flask(__name__)
tool_server = ToolServer()
tool_server.register_tool(sentiment_tool)

@app.route('/tools/<tool_name>/execute', methods=['POST'])
def execute_tool(tool_name):
    tool = tool_server.get_tool(tool_name)
    if tool:
        input_text = request.json['input_text']
        result = tool.execute(input_text)
        return jsonify({'result': result})

Архитектурно схема понятная: POST-запрос с текстом на эндпоинт /tools/SentimentAnalysis/execute — и получаете результат. Но возникает вопрос: автор импортирует Tool и MCPTool из некоего модуля MCP, однако реальный Anthropic MCP SDK (mcp на PyPI) имеет другую структуру API. Классы Tool, MCPTool и ToolServer из примера не соответствуют актуальному SDK. Это может запутать тех, кто попробует воспроизвести код.

Если вы действительно хотите поднять MCP-сервер, смотрите официальную документацию Anthropic и пакет mcp. Там всё устроено иначе — через декораторы и спецификацию JSON Schema для описания инструментов.

Один важный нюанс

Автор справедливо предупреждает: если зарегистрировать инструмент после старта сервера, он может быть недоступен до перезапуска. Это реальная проблема для динамических систем. Решение — механизм горячей перерегистрации, но в статье он остаётся на уровне «consider implementing». Практической реализации нет.

Что это значит на практике

MCP действительно становится заметным трендом. Cursor, Claude Desktop, Windsurf — всё больше ИИ-инструментов поддерживают подключение внешних серверов. Если вы разрабатываете ИИ-агента, который должен работать с базой данных, API погоды, калькулятором или корпоративной CRM — MCP-сервер с набором инструментов это чистый способ организовать такую интеграцию.

Преимущества:

• Стандартизация. Один сервер работает с любым MCP-клиентом.
• Масштабируемость. Добавляете новый инструмент — он автоматически виден всем подключённым агентам.
• Изоляция. Логика инструментов живёт отдельно от логики агента.

Но есть и сложности:

• Безопасность. Открытый MCP-сервер — это открытый API. Нужна аутентификация, rate limiting, валидация входных данных.
• Состояние. MCP по умолчанию stateless. Если инструменту нужно помнить предыдущие вызовы, придётся реализовывать это самостоятельно.
• Зрелость экосистемы. Стандарт всё ещё молодой, документация местами сырковатая, а примеры вроде разобранного выше — не всегда корректны.

Итого

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

Если вы хотите попробовать MCP на практике — начните с официального репозитория Anthropic. Там есть рабочие примеры, актуальный SDK и спецификация протокола. А для серьёзных агентов на LangGraph — документация LangChain про интеграцию с MCP будет куда полезнее, чем поиск слова «love» в строке.