MCP или API: когда использовать MCP, а когда прямой HTTP для AI-инструментов

При подключении AI-агента к внешним инструментам и API есть два основных подхода: использовать Model Context Protocol (MCP) как слой абстракции или вызывать API напрямую по HTTP. Оба подхода работают. Они предполагают разные компромиссы в плане гибкости, сложности, производительности и переносимости.

В этой статье сравниваются два подхода на конкретных примерах кода, с анализом задержки и схемой принятия решения.

Для практической проверки уровня прав см. тестирование аутентификации и доступа MCP. Руководство сравнивает реальные ответы 401 и 403 с успешным вызовом приватного агента, а затем проверяет удаление роли.

Два подхода

Прямая интеграция по HTTP

AI-приложение (или его бэкенд) напрямую вызывает внешние API с помощью стандартных HTTP-запросов. Разработчик пишет код для формирования запросов, обработки аутентификации, разбора ответов и передачи результатов обратно в LLM.

┌──────┐     ┌────────┐                        ┌─────────────┐
│ User │────▶│ AI App │──── HTTP request ─────▶│ Weather API │
└──────┘     │        │◀─── JSON response ─────│             │
             │        │                        └─────────────┘
             │        │── result as context ──▶ LLM
             │        │◀── formatted answer ───
             └───┬────┘
                 │
                 ▼
           User gets answer

Интеграция через MCP

AI-приложение подключается к MCP-серверу, который оборачивает внешний API. Приложение использует протокол MCP, чтобы обнаруживать доступные инструменты, вызывать их по имени и получать результаты. MCP-сервер выполняет фактические HTTP-вызовы к внешнему API.

┌──────┐     ┌───────────────────┐              ┌────────────┐     ┌──────────┐
│ User │────▶│ AI App/MCP Client │── JSON-RPC ─▶│ MCP Server │────▶│ HTTP API │
└──────┘     │                   │◀─ JSON-RPC ──│            │◀────│          │
             │                   │              └────────────┘     └──────────┘
             │                   │── result as context ──▶ LLM
             │                   │◀── formatted answer ───
             └─────────┬─────────┘
                       │
                       ▼
                 User gets answer

Ключевое отличие: при прямом HTTP код интеграции с API принадлежит AI-приложению. При MCP он принадлежит MCP-серверу, а AI-приложение просто вызывает инструменты по имени.

MCP-часть этой схемы можно получить, не создавая сервер: Quickchat AI размещает streamable-HTTP MCP-сервер для каждого AI Agent, а превращение вашего агента в MCP-сервер сводится к вставке одного URL в AI-приложение.

Для настройки в Claude создайте собственный коннектор знаний и сверьте его ответы с исходными материалами.

Сравнение кода

Сравним оба подхода на практическом примере: получение репозиториев пользователя GitHub.

Прямая интеграция по HTTP

import httpx

async def get_user_repos(username: str, token: str) -> list[dict]:
    """Получить репозитории пользователя GitHub."""
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {token}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        return [
            {
                "name": r["name"],
                "description": r["description"],
                "stars": r["stargazers_count"],
                "language": r["language"],
                "url": r["html_url"]
            }
            for r in repos
        ]

Чтобы интегрировать это с LLM, вам также нужны:

Определение инструмента в формате, который ожидает LLM (схема OpenAI function calling, схема Claude tool use и т. д.)
Код для разбора вызова инструмента от LLM, вызова get_user_repos и вставки результата обратно в диалог
Обработка ошибок для HTTP-сбоев, лимитов запросов и истечения срока действия аутентификации

MCP-сервер

from mcp.server.fastmcp import FastMCP
import httpx

mcp = FastMCP("github-server")

GITHUB_TOKEN = os.environ["GITHUB_TOKEN"]

@mcp.tool()
async def get_user_repos(username: str) -> str:
    """Получить 10 недавно обновленных репозиториев пользователя GitHub.

    Args:
        username: имя пользователя GitHub для поиска
    """
    async with httpx.AsyncClient() as client:
        response = await client.get(
            f"https://api.github.com/users/{username}/repos",
            headers={
                "Authorization": f"Bearer {GITHUB_TOKEN}",
                "Accept": "application/vnd.github.v3+json",
                "X-GitHub-Api-Version": "2022-11-28"
            },
            params={"sort": "updated", "per_page": 10}
        )
        response.raise_for_status()
        repos = response.json()
        lines = []
        for r in repos:
            stars = r["stargazers_count"]
            lang = r["language"] or "неизвестно"
            lines.append(f"- {r['name']} ({lang}, {stars} звезд): {r['description'] or 'Нет описания'}")
        return "\n".join(lines)

if __name__ == "__main__":
    mcp.run(transport="stdio")

Версия с MCP инкапсулирует вызов API, аутентификацию и форматирование ответа внутри сервера. Любой MCP-совместимый клиент может использовать этот инструмент, ничего не зная о GitHub API.

Что меняется для AI-приложения

Аспект	Прямой HTTP	MCP
Определение инструмента	Пишется в нативном формате LLM (схема OpenAI и т. д.)	Автоматически генерируется из MCP-сервера
Аутентификация	Управляется AI-приложением	Управляется MCP-сервером
Разбор ответа	AI-приложение извлекает и форматирует данные	MCP-сервер возвращает заранее отформатированный результат
Обработка ошибок	AI-приложение обрабатывает HTTP-ошибки	MCP-сервер обрабатывает ошибки, возвращает структурированные сообщения об ошибках
Добавление нового инструмента	Написать новый код в AI-приложении	Подключиться к новому MCP-серверу (или добавить инструмент в существующий сервер)
Смена LLM	Переписать определения инструментов под новый формат LLM	Изменения не нужны

Сравнение производительности

MCP добавляет слой между AI-приложением и внешним API. У этого слоя есть своя цена.

Задержка

Для транспорта stdio (локальных MCP-серверов) накладные расходы минимальны: запуск процесса при старте (однократно, обычно менее 100ms) и межпроцессное взаимодействие на сообщение (менее миллисекунды на современных системах). На практике вызов внешнего API определяет основную часть общей задержки.

Для удаленных MCP-серверов (Streamable HTTP или SSE) добавляется один HTTP round-trip между клиентом и MCP-сервером, а также HTTP round-trip от MCP-сервера к внешнему API. Если MCP-сервер и внешний API находятся рядом, накладные расходы малы (единицы миллисекунд). Если они находятся в разных регионах, задержка суммируется. Однако пользователь редко замечает именно транспорт: при создании агента для справочного центра на размещенном MCP-сервере Notion 248 вызовов инструментов в среднем занимали 2.7 секунды каждый, и почти все это время уходило на поиск в Notion и рендеринг страниц, а не на промежуточный hop.

Конфигурация	Примерная добавленная задержка
Локальный MCP-сервер (stdio)	< 1ms на вызов инструмента
Удаленный MCP-сервер (тот же регион, что и API)	1-5ms на вызов инструмента
Удаленный MCP-сервер (другой регион относительно API)	10-50ms на вызов инструмента

Для большинства сценариев AI-агентов, где инференс LLM занимает 500ms-5s, накладные расходы MCP несущественны.

Управление соединениями

Прямой HTTP: ваше приложение управляет соединениями с каждым внешним API. Это означает обработку пулов соединений, логики повторных попыток и лимитов запросов для каждого API.

MCP: ваше приложение управляет одним соединением на MCP-сервер. Сервер управляет соединением с внешним API. Если у вас 10 инструментов, распределенных по 3 MCP-серверам, вы управляете 3 соединениями вместо 10.

Когда использовать MCP

Несколько интеграций с инструментами

Если вашему AI-приложению нужно подключаться к 5+ внешним сервисам, MCP снижает нагрузку на интеграцию. Вместо того чтобы писать и поддерживать кастомные API-клиенты для каждого сервиса, вы подключаетесь к MCP-серверам (многие из них доступны как open-source-проекты).

Переносимость между AI-платформами

Если вы создаете MCP-серверы для своих инструментов, эти серверы работают с любым MCP-клиентом: Claude Desktop, Cursor, Windsurf, кастомными приложениями и платформами вроде Quickchat AI. При прямом HTTP вам пришлось бы заново реализовывать определения инструментов для формата каждой платформы.

Динамическое обнаружение инструментов

MCP поддерживает обнаружение инструментов во время выполнения через tools/list. AI-приложение может подключиться к серверу и узнать, какие инструменты доступны, без какой-либо жестко заданной конфигурации. Это полезно в сценариях, где инструменты часто меняются или настраиваются пользователем.

Разделение ответственности

Если разные команды отвечают за разные инструменты, MCP дает четкую границу. Команда, которая владеет интеграцией с Salesforce, создает и поддерживает MCP-сервер Salesforce. Команда AI-приложения подключается к нему, не разбираясь в API Salesforce. Изменения в API Salesforce обрабатываются в MCP-сервере без изменений в AI-приложении.

Когда использовать прямой HTTP

Одна или две интеграции

Если вашему AI-агенту нужно вызывать только один API (например, запрос к базе данных), накладные расходы на запуск MCP-сервера не нужны. Прямой HTTP-вызов проще и состоит из меньшего числа компонентов.

Вам также не нужно писать запрос вручную. Конструктор API Action по описанию на естественном языке читает документированный REST API, генерирует метод, URL, параметры и описание, а затем позволяет протестировать реальный ответ перед включением.

Максимальный контроль над запросами

MCP-серверы скрывают HTTP-детали. Если вам нужен точный контроль над построением запроса (конкретные заголовки, параметры строки запроса, подписание запросов или нестандартная аутентификация), прямой HTTP дает этот контроль без борьбы со слоем абстракции.

Операции, чувствительные к задержке

Если важна каждая миллисекунда (например, голосовые агенты реального времени, где вызовы инструментов должны завершаться в рамках строгих временных бюджетов), удаление слоя MCP убирает один hop.

HTTP-вызовы вне AI

Если HTTP-вызов не инициируется AI-агентом (например, cron-задача на бэкенде, которая синхронизирует данные), MCP не имеет отношения к задаче. MCP специально спроектирован для коммуникации AI с инструментами. Обычные бэкенд-сервисы должны использовать обычные HTTP-клиенты.

Гибридный подход

Многие production-системы используют оба подхода. Паттерн:

MCP для интеграций с инструментами, которые AI-агент вызывает во время диалогов (поиск в CRM, создание тикетов, запросы к knowledge base)
Прямой HTTP для внутренних операций бэкенда, вебхуков и взаимодействия между системами

Так Quickchat AI работает внутри. Платформа поддерживает как HTTP Request Actions (прямые API-вызовы с шаблонизацией параметров), так и Remote MCP Actions (подключения к внешним MCP-серверам). Вы выбираете подходящий способ для каждой интеграции:

Тип интеграции	Рекомендуемый подход
Простой API-вызов с известными параметрами	HTTP Request Action
Сложная интеграция с несколькими связанными инструментами	Remote MCP Action
Сторонний сервис с существующим MCP-сервером	Remote MCP Action
Внутренний API с кастомной аутентификацией	HTTP Request Action
Настраиваемый пользователем инструмент	Remote MCP Action

Подробное сравнение того, как это работает на практике, включая различия между OpenAI GPT Actions и MCP, см. в статье GPT Actions vs MCP.

Схема принятия решения

Используйте эту блок-схему для выбора:

Инструмент вызывает AI-агент? Если нет (это операция бэкенда), используйте прямой HTTP.
Сколько внешних инструментов вам нужно? Если 1-2, прямой HTTP проще. Если 3+, рассмотрите MCP.
Существует ли готовый MCP-сервер для сервиса? Если да, его использование экономит время разработки.
Нужно ли, чтобы интеграция работала на нескольких AI-платформах? Если да, MCP обеспечивает переносимость.
Критична ли задержка (бюджет менее 100ms на вызовы инструментов)? Если да, измерьте накладные расходы MCP и примите решение по результатам.
Разные команды отвечают за разные интеграции? Если да, модель MCP «один сервер на интеграцию» помогает четко разграничить ответственность.

На практике, если вы создаете AI-агента, которому нужно взаимодействовать с внешними сервисами, MCP все чаще становится выбором по умолчанию. Экосистема готовых серверов уже достаточно велика, чтобы часто можно было начать без написания серверного кода.

Дополнительные материалы

Подключите вашего AI Agent к удаленному MCP-серверу: пошаговое добавление реальных инструментов для вашего агента
Как работает Model Context Protocol. Объяснение MCP: введение в MCP
GPT Actions vs MCP: сравнение с подходом OpenAI
Спецификация MCP: официальная спецификация протокола
HubSpot AI Actions: пример AI Actions на основе HTTP на практике
Инцидент OpenAI Hugging Face: что на самом деле произошло: пошаговый разбор инцидента и что на самом деле означает взлом