GPT Actions и MCP: техническое сравнение

GPT Actions от OpenAI и Model Context Protocol (MCP) от Anthropic решают одну и ту же базовую задачу: позволяют AI-модели вызывать внешние инструменты и API во время разговора. Они решают ее очень разными способами.

Эта статья представляет собой техническое сравнение обоих подходов. В ней рассматриваются архитектура, механика протокола, аутентификация, обнаружение инструментов и компромиссы, которые важны при выборе между ними (или при использовании обоих).

Что такое GPT Actions?

GPT Actions, это механизм OpenAI, который позволяет Custom GPTs (и, шире, ассистентам, созданным через OpenAI API) вызывать внешние HTTP API. Концепция появилась вместе с GPT Store в конце 2023 года и развилась из более ранней системы ChatGPT Plugins.

Основная идея: вы предоставляете спецификацию OpenAPI (версии 3.0 или 3.1), которая описывает эндпоинты, параметры и схемы ответов вашего API. Система OpenAI разбирает эту спецификацию и представляет эндпоинты модели как вызываемые инструменты. Когда модель решает вызвать один из них, серверы OpenAI выполняют HTTP-запрос от имени пользователя.

Ниже приведена минимальная схема OpenAPI, которая определяет одно действие для поиска клиента по email:

openapi: "3.1.0"
info:
  title: "API поиска клиентов"
  version: "1.0.0"
servers:
  - url: "https://api.example.com"
paths:
  /customers/search:
    get:
      operationId: "searchCustomer"
      summary: "Найти клиента по email"
      parameters:
        - name: "email"
          in: "query"
          required: true
          schema:
            type: "string"
            format: "email"
          description: "Email-адрес клиента"
      responses:
        "200":
          description: "Клиент найден"
          content:
            application/json:
              schema:
                type: "object"
                properties:
                  id:
                    type: "string"
                  name:
                    type: "string"
                  email:
                    type: "string"
                  plan:
                    type: "string"

Вы вставляете или загружаете эту схему в GPT Builder (или указываете на нее через URL), настраиваете аутентификацию, и Custom GPT теперь может вызывать GET /customers/search?email=... всякий раз, когда модель считает это релевантным. (Написание спецификации можно автоматизировать: например, Quickchat AI генерирует эквивалентное действие из описания в одно предложение, опираясь на актуальную документацию API.)

Ключевые архитектурные свойства GPT Actions:

• Выполнение на стороне сервера: инфраструктура OpenAI выполняет исходящий HTTP-вызов. Ваш API получает запрос из диапазона IP-адресов OpenAI, а не из браузера конечного пользователя.
• OpenAPI как формат схемы: модель использует поля operationId, summary и description из спецификации OpenAPI, чтобы понять, когда и как вызывать каждый эндпоинт.
• Только REST/HTTP: Actions ограничены стандартными HTTP-методами (GET, POST, PUT, DELETE, PATCH) поверх HTTPS.
• Варианты аутентификации: OAuth 2.0, API key (передается как заголовок или query-параметр) или без аутентификации. OpenAI обрабатывает поток обмена OAuth-токенами от имени пользователя.
• Статические определения инструментов: набор доступных действий фиксируется во время настройки. Модель не может обнаруживать новые эндпоинты во время выполнения.

Что такое MCP?

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

Мы написали полное руководство о том, как работает MCP, где протокол разобран с базовых принципов. Краткая версия: MCP определяет клиент-серверную архитектуру, в которой AI-приложение (MCP-клиент) подключается к одному или нескольким MCP-серверам, обнаруживает доступные инструменты через запрос tools/list и вызывает их через сообщения tools/call. Для взаимодействия используется JSON-RPC 2.0.

Вот тот же инструмент поиска клиента, выраженный как определение MCP-инструмента:

{
  "name": "search_customer",
  "description": "Найти клиента по email-адресу",
  "inputSchema": {
    "type": "object",
    "properties": {
      "email": {
        "type": "string",
        "description": "Email-адрес клиента"
      }
    },
    "required": ["email"]
  }
}

Это определение находится внутри MCP-сервера (небольшой программы, которая оборачивает вашу бизнес-логику). Когда MCP-клиент отправляет запрос tools/call с name: "search_customer" и arguments: {"email": "user@example.com"}, сервер выполняет код, стоящий за этим инструментом (вызов API, запрос к базе данных, чтение файла), и возвращает результат. Если вы хотите предоставлять не сырую бизнес-логику, а AI-ассистента, сервер можно вообще не писать: ваш Quickchat AI Agent можно предоставить как MCP-инструмент с размещенным URL.

Сравнение архитектур

Два подхода отличаются тем, где выполняется код, как проходит коммуникация и какие абстракции они предоставляют.

GPT Actions: централизованный подход, ориентированный на HTTP

User <-> ChatGPT (OpenAI servers) --HTTPS--> Your API server

Модель и исполнитель действия находятся вместе на стороне OpenAI. Когда модель решает вызвать действие, backend OpenAI формирует HTTP-запрос на основе спецификации OpenAPI, отправляет его в ваш API, получает ответ и передает результат обратно модели. Клиент пользователя (браузер, мобильное приложение) никогда не взаимодействует с вашим API напрямую.

Это означает:

1. Ваш API должен быть публично доступен по HTTPS (или как минимум быть доступен из инфраструктуры OpenAI).
2. Задержка включает round-trip от OpenAI до вашего сервера и обратно.
3. Все данные запросов и ответов проходят через серверы OpenAI.

MCP: децентрализованный подход, ориентированный на протокол

User <-> AI Application (MCP Client) <--JSON-RPC--> MCP Server <-> Your API / DB / service

MCP-клиент работает там, где работает AI-приложение. Для Claude Desktop это машина пользователя. Для облачного AI-агента (например, Quickchat AI) MCP-клиент работает на backend агента. MCP-сервер может работать локально (взаимодействуя через stdio), в той же сети или удаленно по HTTP с Server-Sent Events (SSE) либо более новым транспортом Streamable HTTP.

Это означает:

1. MCP-серверы могут получать доступ к локальным ресурсам (файлам, базам данных, localhost-сервисам), которые не открыты в публичный интернет.
2. Коммуникация двунаправленная. Серверы могут отправлять уведомления клиентам (например, когда ресурс изменился).
3. Протокол не зависит от транспорта. Он работает через stdio-каналы, SSE или обычный HTTP.

Сравнительная таблица

Технический разбор: пример интеграции

Чтобы сделать различия конкретными, рассмотрим распространенную задачу: запрос к базе данных PostgreSQL для получения заказов клиента и возврат результатов пользователю.

Подход GPT Actions

Вам нужно создать и разместить HTTP API перед вашей базой данных:

# Flask API server (simplified)
from flask import Flask, request, jsonify
import psycopg2

app = Flask(__name__)

@app.route("/orders", methods=["GET"])
def get_orders():
    customer_email = request.args.get("email")
    conn = psycopg2.connect("dbname=mydb user=myuser")
    cur = conn.cursor()
    cur.execute(
        "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
        (customer_email,)
    )
    rows = cur.fetchall()
    cur.close()
    conn.close()
    return jsonify([
        {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
        for r in rows
    ])

Затем вы пишете спецификацию OpenAPI для этого эндпоинта, разворачиваете API с TLS, настраиваете аутентификацию и вставляете спецификацию в GPT Builder. OpenAI делает остальное: читает спецификацию, показывает модели доступную операцию и выполняет HTTP-вызов при необходимости.

Итоговая настройка включает: работающий API-сервер, публичный HTTPS-эндпоинт, спецификацию OpenAPI и конфигурацию GPT Action в UI OpenAI.

Подход MCP

Вы пишете MCP-сервер, который оборачивает тот же запрос к базе данных:

# MCP server using the mcp Python SDK
from mcp.server import Server
from mcp.types import Tool, TextContent
import psycopg2
import json

server = Server("orders-server")

@server.list_tools()
async def list_tools():
    return [
        Tool(
            name="get_orders",
            description="Найти заказы клиента по email",
            inputSchema={
                "type": "object",
                "properties": {
                    "email": {
                        "type": "string",
                        "description": "Email-адрес клиента"
                    }
                },
                "required": ["email"]
            }
        )
    ]

@server.call_tool()
async def call_tool(name: str, arguments: dict):
    if name == "get_orders":
        conn = psycopg2.connect("dbname=mydb user=myuser")
        cur = conn.cursor()
        cur.execute(
            "SELECT order_id, product, amount, status FROM orders WHERE customer_email = %s",
            (arguments["email"],)
        )
        rows = cur.fetchall()
        cur.close()
        conn.close()
        results = [
            {"order_id": r[0], "product": r[1], "amount": float(r[2]), "status": r[3]}
            for r in rows
        ]
        return [TextContent(type="text", text=json.dumps(results, indent=2))]

Если MCP-сервер работает локально (через stdio), он может подключаться напрямую к базе данных на localhost или в локальной сети. Публичный эндпоинт не нужен. Если сервер работает удаленно, ему нужен HTTP-эндпоинт, но он взаимодействует с использованием JSON-RPC поверх SSE или Streamable HTTP, а не сырого REST.

Итоговая настройка для локального использования включает: скрипт MCP-сервера, конфигурацию MCP-клиента (с указанием команды сервера) и подключение к базе данных. Спецификация OpenAPI, TLS-сертификат и публичный API не нужны.

Ключевые практические различия

Путь GPT Actions требует больше инфраструктуры (развернутый HTTP-сервис), но использует существующие паттерны REST API, которые уже знакомы большинству команд. Если у вас уже есть REST API, добавление GPT Action в основном сводится к написанию спецификации OpenAPI.

Путь MCP требует меньше инфраструктуры для локальных сценариев, но вводит новый протокол, который вашей команде нужно изучить. Для удаленных развертываний требования к инфраструктуре похожи на GPT Actions, но модель коммуникации другая (постоянные соединения, фрейминг JSON-RPC, двунаправленные уведомления).

Как Quickchat AI работает с обоими подходами

Система AI Actions в Quickchat AI поддерживает два отдельных типа действий, которые соответствуют этим двум парадигмам: HTTP Request Actions и Remote MCP Actions.

HTTP Request Actions

HTTP Request Actions концептуально похожи на GPT Actions. Вы настраиваете HTTP-эндпоинт, метод, заголовки, query-параметры и шаблон JSON-тела. AI Agent собирает значения параметров из разговора, а backend Quickchat выполняет HTTP-запрос на стороне сервера.

HTTP Request Action состоит из:

• URL эндпоинта с плейсхолдерами {{parameter}} (например, https://api.hubapi.com/crm/v3/objects/contacts)
• HTTP-метода (GET, POST, PATCH, PUT, DELETE)
• Заголовков (включая токены авторизации, подставляемые на стороне сервера)
• Шаблона JSON-тела с плейсхолдерами параметров
• Query-параметров с плейсхолдерами
• Набора типизированных параметров (string, number, boolean, float) с описаниями, флагами обязательности и значениями по умолчанию

Во время выполнения AI определяет, какие параметры заполнить, на основе контекста разговора. Backend подставляет значения параметров в URL, заголовки, тело и query string, заменяя плейсхолдеры {{param_name}}. Затем он выполняет HTTP-запрос и возвращает ответ AI для интерпретации.

Подробный пример см. в нашем руководстве по HubSpot AI Actions.

Remote MCP Actions

Remote MCP Actions подключают AI Agent к внешнему MCP-серверу. Вместо определения отдельных HTTP-эндпоинтов вы указываете URL MCP-сервера и необязательные учетные данные для аутентификации (bearer token и/или пользовательские заголовки). Backend Quickchat работает как MCP-клиент: подключается к удаленному серверу, обнаруживает доступные инструменты через стандартный вызов протокола tools/list и представляет их AI-модели.

Конфигурация требует:

• URL MCP-сервера (HTTPS-эндпоинт, обслуживающий транспорт MCP Streamable HTTP или SSE)
• Необязательный токен аутентификации
• Необязательные пользовательские заголовки
• Список обнаруженных инструментов с индивидуальными переключателями active/inactive
• Настройку активации инструментов по умолчанию (будут ли новые обнаруженные инструменты активны по умолчанию)

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

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

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

Используйте HTTP Request Actions, когда:

• Вы интегрируетесь с конкретным эндпоинтом REST API
• Вам нужен точный контроль над форматом запроса (заголовки, структура тела, query params)
• У API нет опубликованного MCP-сервера
• Вам нужна подстановка учетных данных на стороне сервера (например, OAuth-токены для HubSpot, Zendesk и т. д.)

Используйте Remote MCP Actions, когда:

• Сервис публикует MCP-сервер
• Вы хотите подключить несколько инструментов одного сервиса в одном действии
• Вам нужно динамическое обнаружение инструментов (инструменты, доступные AI, могут меняться при обновлении MCP-сервера)
• Вы строите многоагентную систему, где один AI делегирует задачи другому через MCP

Плюсы и минусы

GPT Actions

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

• Знакомая технология. Если у вас есть существующий REST API, у вас уже есть большая часть необходимого. Написание спецификации OpenAPI хорошо задокументировано, а инструменты зрелые.
• Формат OpenAPI широко распространен. Спецификации можно автоматически генерировать из многих web-фреймворков (FastAPI, Express с swagger-jsdoc, Spring Boot со springdoc).
• OpenAI обрабатывает выполнение HTTP-запросов, TLS termination и обработку ошибок в своей инфраструктуре.
• Поддержка OAuth 2.0 встроена, включая автоматическое обновление токенов.

Недостатки:

• Привязка к экосистеме OpenAI. Действие, созданное для Custom GPT, нельзя повторно использовать с Claude, Gemini или любым другим поставщиком моделей без повторной реализации.
• Ваш API должен быть публично доступен. Нет поддержки локальных ресурсов или ресурсов в частной сети.
• Нет динамического обнаружения инструментов. Добавление нового эндпоинта требует обновления спецификации OpenAPI и перенастройки GPT.
• Только однонаправленный подход. Ваш API не может отправлять модели обновления или уведомления вне HTTP-ответов.
• Все данные проходят через серверы OpenAI, что может быть проблемой для чувствительных рабочих нагрузок.
• Лимиты частоты и таймауты выполнения контролируются OpenAI, а не вами.

MCP

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

• Не зависит от поставщика. Один и тот же MCP-сервер работает с Claude, Cursor, Quickchat AI и любым другим клиентом, который реализует протокол.
• Поддерживает локальные ресурсы. MCP-сервер, работающий через stdio, может получать доступ к файлам, базам данных и сервисам на локальной машине, не открывая ничего в интернет.
• Динамическое обнаружение инструментов. AI может запрашивать у сервера доступные инструменты во время выполнения. Инструменты можно добавлять, удалять или обновлять без перенастройки клиента.
• Двунаправленная коммуникация. Серверы могут уведомлять клиентов об изменениях (например, файл был изменен, новая запись была создана).
• Stateful-сессии. Соединение сохраняется между несколькими вызовами инструментов в рамках разговора, что позволяет реализовывать рабочие процессы, которым нужен контекст предыдущих вызовов.
• Открытая спецификация. Любой может изучить, реализовать или расширить протокол.

Недостатки:

• Более молодая экосистема. Протокол был опубликован в конце 2024 года, поэтому инструменты, документация и знания сообщества все еще развиваются по сравнению с OpenAPI.
• Требуется запуск MCP-сервера. Для удаленных развертываний это означает хостинг дополнительного сервиса (хотя он может быть легковесным).
• Нет стандартизированной спецификации аутентификации (по состоянию на начало 2026 года). Реализации различаются: аутентификация на основе токенов, пользовательские заголовки и OAuth-расширения. Спецификация MCP Authorization все еще развивается.
• Фрейминг JSON-RPC добавляет слой абстракции, который может быть непривычен командам, привыкшим к REST.
• Поддержка клиентов различается. Не все AI-приложения поддерживают все транспорты или функции MCP.

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

Выбор зависит от ваших ограничений:

Выбирайте GPT Actions, если:

• Вы создаете решение исключительно для ChatGPT или OpenAI API.
• У вас уже есть публичный REST API со спецификацией OpenAPI.
• Вам нужно, чтобы платформа обрабатывала OAuth 2.0 за вас.
• Вам нужен самый простой путь от “существующий API” к “инструмент, вызываемый AI.”

Выбирайте MCP, если:

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

Используйте оба подхода, если:

• У вас есть существующий REST API, который вы хотите предоставить как GPT Action для пользователей ChatGPT, но вы также хотите опубликовать MCP-сервер для Claude, Cursor и других клиентов. Базовая бизнес-логика может быть общей, а адаптер протокола остается тонким слоем поверх нее.

Тенденция к сближению

GPT Actions и MCP начинались с разных проектных философий (ориентация на HTTP и ориентация на протокол), но разрыв сокращается.

OpenAI добавила поддержку MCP в Agents SDK в марте 2025 года, позволив агентам на базе OpenAI подключаться к MCP-серверам наряду с традиционным function calling. Это не заменяет GPT Actions (которые остаются способом добавить tool calling в Custom GPTs в ChatGPT), но показывает, что OpenAI признает MCP жизнеспособным стандартом для взаимодействия агентов с инструментами.

Со стороны MCP протокол теперь поддерживает транспорт Streamable HTTP, из-за чего удаленные MCP-серверы больше похожи на традиционные HTTP-сервисы. MCP-сервер за эндпоинтом Streamable HTTP архитектурно не так далек от REST API, хотя внутри он по-прежнему использует JSON-RPC, а не REST-соглашения.

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

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

• Спецификация MCP
• Как работает Model Context Protocol: объяснение MCP
• MCP и HTTP
• Подключите к AI Agent live-инструменты с удаленного MCP-сервера: практическая сборка
• Документация OpenAI Actions
• Спецификация OpenAPI
• Каталог MCP-серверов
• Сложности создания AI Agent поверх Shopify MCP