MCP или API: когда использовать MCP или прямой HTTP

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

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

Два подхода

Прямая интеграция по 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-приложение.

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

Сравним оба подхода на практическом примере: получение репозиториев пользователя 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-приложения

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

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

Задержка

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

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

Для большинства сценариев AI-агентов, где inference 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, создает и поддерживает Salesforce MCP server. Команда AI-приложения подключается к нему, не разбираясь в API Salesforce. Изменения в API Salesforce обрабатываются в MCP-сервере без изменений в AI-приложении.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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