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

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

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

Если вы поддерживаете собственного GPT, в руководстве по миграции GPT описано, как сохранить его инструкции и знания и заново настроить действия, которые не переносятся.

Что такое 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. Когда модель решает вызвать действие, бэкенд OpenAI формирует HTTP-запрос на основе спецификации OpenAPI, отправляет его в ваш API, получает ответ и передает результат обратно модели. Клиент пользователя (браузер, мобильное приложение) никогда не взаимодействует с вашим API напрямую.

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

1. Ваш API должен быть публично доступен по HTTPS (или как минимум быть доступен из инфраструктуры OpenAI).
2. Задержка включает время на передачу запроса от 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-клиент работает на бэкенде агента. 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 собирает значения параметров из разговора, а бэкенд 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 определяет, какие параметры заполнить, на основе контекста разговора. Бэкенд подставляет значения параметров в URL, заголовки, тело и строку запроса, заменяя плейсхолдеры {{param_name}}. Затем он выполняет HTTP-запрос и возвращает ответ AI для интерпретации.

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

Remote MCP Actions

Remote MCP Actions подключают AI Agent к внешнему MCP-серверу. Вместо определения отдельных HTTP-эндпоинтов вы указываете URL MCP-сервера и необязательные учетные данные для аутентификации (bearer-токен и/или пользовательские заголовки). Бэкенд 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-действий для каждого эндпоинта.

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

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

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

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

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

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

GPT Actions

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

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