← Cloudflare One / cloudflare-one / access-controls / ai-controls

порталы MCP-сервера

Портал MCP-сервера объединяет несколько Серверы Model Context Protocol (MCP) ↗ на единую конечную точку HTTP.

В этом руководстве объясняется, как добавить MCP-серверы в Cloudflare Access, создать портал MCP с настроенными инструментами и политиками, а также подключить к нему пользователей с помощью MCP-клиента.

Порталы MCP-сервера предоставляют следующие возможности:

• Упрощённый доступ к нескольким серверам MCP: Порталы серверов MCP поддерживают как неаутентифицированные серверы MCP, так и серверы MCP, защищённые с помощью OAuth (например, через Access for SaaS или сторонний поставщик OAuth). Пользователи входят по URL портала через Cloudflare Access, после чего им предлагается отдельно пройти аутентификацию на каждом сервере, который требует OAuth.
• Совместимость с протоколом MCP: Портал поддерживает MCP без сохранения состояния 2026-07-28 и более ранних клиентов и серверов Streamable HTTP версии 2025 года. Портал сам выбирает поддерживаемый протокол для каждого соединения, без необходимости настройки протокола.
• Настраиваемые инструменты для каждого портала: Администраторы могут настраивать MCP-портал под конкретный сценарий использования: они выбирают инструменты и шаблоны промптов, которые должны быть доступны пользователям через портал. Это позволяет пользователям работать с отобранным набором инструментов и промптов: чем меньше внешнего контекста передаётся модели ИИ, тем точнее обычно её ответы.
• Псевдонимы инструментов и промптов: Администраторы могут Переименовать инструменты и промпты и измените их описания на уровне портала или сервера, не изменяя сам исходный сервер MCP. Псевдонимы помогают конечным пользователям находить нужный инструмент, а ИИ-агентам выбирать правильный.
• Оптимизация контекста: Порталы поддерживают параметры запроса, которые снижают использование контекстного окна за счёт минимизации или скрытия определений инструментов. См. Оптимизировать контекст для получения подробностей.
• Поддержка небраузерных клиентов: Клиенты MCP проходят аутентификацию в портале с помощью стандартного OAuth 2.0 Authorization Code Flow через Managed OAuth. Эта конфигурация managed OAuth применяется к приложению Access portal. Она отдельна от вышестоящего OAuth, который используют отдельные MCP-серверы в portal. Клиенты, не являющиеся браузерами, получают 401 ответ с WWW-Authenticate заголовок, указывающий на конечные точки обнаружения OAuth в Access, вместо перенаправления браузера. Вы также можете подключиться, используя Токены служб Access для доступа между машинами.
• Code Mode: Code Mode объединяет все вышестоящие инструменты в два инструмента для поиска и выполнения кода. ИИ-агент пишет код на JavaScript, который вызывает типизированные методы для каждого инструмента. Код выполняется в изолированной Dynamic Worker среде. Администраторы могут указывать, будет ли Code Mode недоступен, опционален, включён по умолчанию или обязателен. См. Code Mode для инструкций по настройке и подключению.
• Observability: После подключения ИИ-агента пользователя к порталу Cloudflare Access регистрирует отдельные запросы, выполненные с помощью инструментов портала. При желании вы можете направить трафик портала через Cloudflare Gateway для более детального журналирования HTTP и сканирования на предмет предотвращения потери данных (DLP).

На следующей схеме показано, как запросы проходят через портал сервера MCP.

1. MCP-клиент подключается к URL-адресу портала и получает 401 ответ с метаданными обнаружения OAuth.
2. Пользователь проходит аутентификацию через Cloudflare Access с помощью своего поставщика идентификации или использует токен службы заголовки.
3. Access проверяет личность пользователя, а портал возвращает инструменты, доступные из включённых вышестоящих серверов.
4. Когда пользователь вызывает инструмент, портал определяет целевой сервер по пространство имён инструмента, подставляет нужные учётные данные и проксирует запрос. Если Маршрутизация Gateway включён, запрос проходит через Cloudflare Gateway для журналирования HTTP-трафика и проверки DLP.
5. Вышестоящий сервер обрабатывает запрос и возвращает ответ по тому же пути.

Для серверов с автоматической регистрацией OAuth фоновая синхронизация инструментов и подсказок выполняется примерно каждые два часа с использованием учетных данных администратора. Эта синхронизация подключается напрямую к вышестоящим серверам и не проходит через Gateway.

Портал принимает не имеющие состояния MCP 2026-07-28 ↗ и более ранних клиентов Streamable HTTP версии 2025 года по адресу /mcp конечная точка. Портал выбирает протокол для каждого запроса. Настраивать версию протокола не нужно.

Портал подключается к upstream-серверам MCP с помощью Streamable HTTP ↗ или SSE ↗ транспорт. Для серверов Streamable HTTP портал проверяет MCP 2026-07-28 поддержку и использует протокол без отслеживания состояния (stateless), если он доступен. Если вышестоящий сервер не поддерживает его, портал переходит на handshake версии 2025 в рамках того же подключения. Подключения SSE всегда используют устаревший протокол.

Выбор протокола клиента и вышестоящего сервера выполняется независимо. Например, клиент версии 2025 года может подключаться через портал к вышестоящему серверу без сохранения состояния. Клиент без сохранения состояния также может подключаться к устаревшему вышестоящему серверу.

Указывать, какой транспорт использует ваш вышестоящий сервер, не нужно. Портал сам определяет нужный транспорт, последовательно пробуя несколько стратегий подключения:

Если попытка подключения возвращает 404, 405, или 406 ошибка, портал переходит к следующей стратегии. Все остальные ошибки останавливают попытку подключения.

Каждый портал предоставляет клиентам MCP следующие встроенные инструменты в дополнение к инструментам вышестоящего сервера:

Когда оптимизация контекста включён, в зависимости от режима становятся доступны дополнительные инструменты:

MCP 2026-07-28 запросы не имеют состояния и не создают сессию протокола MCP. Портал сохраняет аутентификацию, выбор сервера и состояние upstream OAuth для authorization grant портала пользователя.

Более ранние версии клиента 2025 года создают сессию, которая сохраняется до тех пор, пока пользователь не отключится или пока сессия не истечёт через 24 часа бездействия.

Пользователи могут включать и отключать отдельные серверы, не разрывая соединение. Для запросов без сохранения состояния переключение серверов применяется к каждому запросу, использующему один и тот же grant авторизации портала. Для устаревших клиентов переключатели действуют только в рамках сессии MCP. Переключатели не влияют на других пользователей.

Порталы MCP-серверов ранее именовались как Agents Gateway в некоторых контекстах. Пути API, ресурсы Terraform и внутренние кодовые базы могут по-прежнему использовать agents_gateway или agw префиксы. Название продукта: порталы MCP-сервера а навигация в дашборде: Элементы управления ИИ.

• Одна активный домен в Cloudflare
• Домен использует либо полная настройка или частичная (CNAME) настройка
• Одна поставщик удостоверений настроено в Cloudflare Zero Trust

Добавьте отдельные серверы MCP в Cloudflare Access, чтобы централизованно управлять ими.

Чтобы добавить MCP-сервер:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.

2. Перейдите в MCP-серверы на вкладке.

3. Выберите Добавьте сервер MCP.

4. Введите любое имя для сервера.

5. (Необязательно) Введите пользовательскую строку для ID сервера.

6. В HTTP URL, введите полный URL-адрес вашего MCP-сервера. Например, если вы хотите добавить сервер Cloudflare Documentation MCP ↗, введите https://docs.mcp.cloudflare.com/mcp.

7. Добавить Политики доступа чтобы показать или скрыть сервер в Портал MCP-сервера. Ссылка на MCP-сервер отображается в портале только для пользователей, соответствующих политике Allow. Пользователи, не проходящие политику Allow, не увидят этот сервер ни в одном портале.

8. Выберите Сохранить и подключить сервер.

9. Если MCP-сервер поддерживает OAuth, вы будете перенаправлены для входа к своему OAuth-провайдеру. Войти можно в любую учётную запись на MCP-сервере. Учётная запись, использованная для аутентификации, будет служить учётными данными администратора для этого MCP-сервера. Вы можете настроить портал MCP использовать эти учётные данные администратора для отправки запросов.

Cloudflare Access проверит подключение к серверу и получит список ресурсов, подсказок и инструментов. После успешного подключения сервера статус сервера изменится на Готово. Теперь вы можете добавить MCP-сервер в Портал MCP-сервера.

Используйте вручную заданные учётные данные OAuth, если вышестоящий поставщик не поддерживает OAuth Dynamic Client Registration ↗. Этот процесс использует приложение OAuth, которое вы регистрируете у вышестоящего провайдера.

Панель управления использует общий URL обратного вызова Cloudflare при переключении сервера с автоматических учётных данных на ручные:

https://oauth-callbacks.cloudflareaccess.com/cdn-cgi/access/outbound-oauth-callback

Всегда регистрируйте redirect URI, отображаемый в дашборде. Поставщики OAuth обычно требуют точного совпадения URI.

Cloudflare хранит client secret в зашифрованном виде и не возвращает его через панель управления или API. При редактировании сервера оставьте Секрет клиента пустым, чтобы сохранить текущее значение. Чтобы сменить секрет, создайте или активируйте замену у вышестоящего провайдера, введите новое значение и сохраните сервер.

Ручные учётные данные требуют аутентификации для каждого пользователя. Оставьте Требовать аутентификации пользователя включается при добавлении сервера в портал. Сервер остаётся в Ожидание статус, пока первый пользователь не завершит процесс OAuth с вышестоящим сервером. После этого Cloudflare получает возможности сервера и меняет его статус на Готово.

Приложения MCP ↗ : инструменты, которые указывают UI-ресурс в своём описании, также станут доступны после успешного подключения к MCP-серверу. Список MCP-клиентов, поддерживающих MCP Apps, доступен в Матрица поддержки расширений ↗.

Статус сервера MCP отражает состояние синхронизации сервера MCP с Cloudflare Access.

Когда MCP-сервер находится в состоянии Ошибка или Требуется синхронизация состояние, Cloudflare Access предоставляет структурированную информацию, которая поможет вам диагностировать проблему. В панели управления наведите курсор на статус сервера, чтобы увидеть сообщение об ошибке, категорию ошибки (upstream или connection), код статуса HTTP и код ошибки протокола MCP (если применимо). Те же сведения возвращаются через API в виде error_details объект:

К распространённым причинам ошибок сервера относятся истёкшие учётные данные OAuth, недоступные URL-адреса сервера и неправильная конфигурация вышестоящего сервера. Если тип ошибки: upstream_error, проверьте коды ошибок HTTP и MCP, чтобы определить проблему на вышестоящем сервере. Если тип unreachable, убедитесь, что URL-адрес сервера указан верно и доступен.

Чтобы повторно авторизовать MCP-сервер в Cloudflare Access:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.
2. Перейдите в MCP-серверы на вкладке.
3. Выберите сервер, для которого нужно выполнить повторную аутентификацию, затем нажмите Изменить.
4. Выберите Аутентификация сервера.

Вы будете перенаправлены для входа к своему OAuth-провайдеру. Учетная запись, использованная для аутентификации, станет новыми учетными данными администратора для этого MCP server.

Для серверов с автоматической регистрацией OAuth Cloudflare Access синхронизирует инструменты и подсказки примерно каждые два часа. Во время синхронизации Cloudflare подключается к вашему MCP-серверу с помощью учётные данные администратора и получает текущий список инструментов и подсказок. Если срок действия токена доступа OAuth учётных данных администратора истёк, Cloudflare автоматически обновляет его с помощью сохранённого refresh-токена перед подключением.

Чтобы вручную обновить MCP-сервер в Zero Trust:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.
2. Перейдите в MCP-серверы вкладку и найдите сервер, который нужно обновить.
3. Выберите три точки > Возможности синхронизации.

На странице сервера MCP отобразится обновлённый список инструментов и подсказок. Новые инструменты и подсказки автоматически включаются на портале сервера MCP.

Вы также можете запустить синхронизацию через API. Конечная точка синхронизации возвращает текущее состояние сервера после синхронизации, включая обновлённые статус сервера, количество инструментов и сведения об ошибке если синхронизация не удалась.

Когда пользователь авторизует вышестоящий MCP-сервер, требующий OAuth для каждого пользователя, портал от имени пользователя выполняет процесс авторизации OAuth по коду авторизации с этим сервером. В рамках этого процесса портал регистрирует URL обратного вызова (redirect_uri) с вышестоящим сервером. Вышестоящий сервер перенаправляет на этот URL-адрес после того, как пользователь авторизует доступ.

По умолчанию портал использует callback-URL на домене вашего портала:

https://<your-portal-hostname>/servers-callback

Добавьте этот URL-адрес в список разрешённых как URI перенаправления у вышестоящего провайдера OAuth. Провайдеры OAuth обычно требуют точного совпадения полного URI, включая путь.

Если для портала включён общий callback URL, портал использует вместо него URL-адрес, принадлежащий Cloudflare:

https://oauth-callbacks.cloudflareaccess.com/cdn-cgi/access/outbound-oauth-callback

Используйте общий URL обратного вызова, если upstream-поставщики допускают в своём allowlist лишь небольшое количество redirect URI, или если вы хотите использовать единый URL, принадлежащий Cloudflare, для нескольких порталов. Общий URL обратного вызова используется только при явном включении этой функции для портала.

Чтобы создать портал сервера MCP:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.

2. Выберите Добавление портала MCP-сервера.

3. Введите любое имя для портала.

4. В разделе Пользовательский домен, выберите домен для URL портала. Домены должны принадлежать активной зоне в вашем аккаунте Cloudflare. При необходимости можно указать поддомен.

5. Добавление MCP-серверов к порталу.

6. (Необязательно) В разделе MCP-серверы, настроить инструменты и промпты доступный через портал.

7. (Необязательно) Настройте Требовать аутентификации пользователя для серверов, поддерживающих OAuth: - Enabled: (по умолчанию) Пользователю будет предложено использовать собственные учётные данные для входа, чтобы установить соединение с MCP-сервером. - Disabled: пользователи, подключённые к порталу, автоматически получают доступ к серверу MCP через его учётные данные администратора.

8. Добавить Политики доступа чтобы определить пользователей, которые могут подключаться к URL-адресу портала.

9. Выберите Добавьте портал сервера MCP.

10. (Необязательно) Настройка процесса входа для портала.

Теперь пользователи могут подключиться к порталу по адресу https://<subdomain>.<domain>/mcp с помощью MCP-клиента.

Cloudflare Access автоматически создаёт приложение Access для каждого портала MCP-сервера. Вы можете настроить процесс входа на портал, изменив настройки приложения Access:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Приложения.
2. Найдите портал, который вы хотите настроить, а затем выберите три точки > Изменить.
3. Чтобы настроить поставщиков идентификации для портала:
   1. Перейдите в Аутентификация.
   2. Выберите поставщики идентификации который вы хотите включить для своего приложения.
   3. (Рекомендуется) Если вы планируете разрешить доступ только через один поставщик идентификации, включите Применить мгновенную аутентификацию. Конечные пользователи не увидят Страница входа Cloudflare Access. Вместо этого Cloudflare будет перенаправлять пользователей напрямую на событие входа SSO.
4. Чтобы настроить страницу блокировки:
   1. Перейдите в Дополнительные настройки.

   2. Пользовательские страницы блокировки: Выберите, что увидят пользователи при отказе в доступе к приложению.

      • Cloudflare по умолчанию: Перезагрузите страница входа и отображает сообщение о блокировке под логотипом Cloudflare Access. Сообщение по умолчанию: That account does not have access, или вы можете ввести собственное сообщение.
      • Redirect URL: Перенаправление на указанный веб-сайт.
      • Пользовательский шаблон страницы: Отобразите пользовательская страница блокировки размещенный в Cloudflare One.
5. Выберите Save.

Когда вы добавляете сервер MCP в портал, все его инструменты и промпты по умолчанию доступны пользователям портала. Вы можете настроить, какие инструменты и промпты будут доступны, переименовать их с помощью псевдонимов и переопределить их описания.

Чтобы скрыть отдельные инструменты или промпты от пользователей портала:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.
2. Найдите портал, который вы хотите настроить, а затем выберите три точки > Изменить.
3. В разделе MCP-серверы, найдите сервер, инструментами которого нужно управлять.
4. Отключите переключатель рядом с любым инструментом или подсказкой, которые вы хотите скрыть от пользователей.
5. Выберите Save.

Turned-off tools will not appear in the portal's tool list. Users will not be able to call them.

По умолчанию все инструменты и подсказки сервера MCP доступны в портале. Это поведение можно изменить на обратное, чтобы все инструменты были скрыты по умолчанию и открывались только те, что вы явно включили. Это удобно, если сервер MCP предоставляет много инструментов, а вам нужно открыть только отобранное подмножество.

Чтобы настроить список разрешений через API, задайте default_disabled к true в сопоставлении сервера с порталом, а затем явно укажите инструменты, которые нужно предоставить в updated_tools:

{
	"servers": [
		{
			"id": "example-server",
			"default_disabled": true,
			"updated_tools": [
				{
					"name": "search_documents",
					"enabled": true
				},
				{
					"name": "list_projects",
					"enabled": true
				}
			]
		}
	]
}

С default_disabled имеет значение true, только search_documents и list_projects будет доступен пользователям портала. Все остальные инструменты этого сервера будут скрыты.

Псевдонимы позволяют давать инструментам и промптам более понятные названия в портале. Используйте псевдонимы, чтобы:

• Заменяйте неясные названия инструментов названиями, соответствующими терминологии вашей организации.
• Добавьте или улучшите описания, чтобы ИИ-агенты выбирали правильный инструмент.
• Стандартизируйте именование на нескольких MCP-серверах в портале.

Псевдонимы должны содержать от 1 до 40 символов и могут включать только буквы, цифры, дефисы и знаки подчёркивания. Имя должно начинаться и заканчиваться буквенно-числовым символом. Значение должно соответствовать ^[a-zA-Z0-9]+([_-][a-zA-Z0-9]+)*$. Например, search_customer_records или get-user-profile. Никакие два инструмента или промпта на одном сервере не могут иметь одинаковое имя, независимо от того, является ли это имя псевдонимом или исходным именем вышестоящего сервера.

Псевдонимы можно задавать на двух уровнях. Псевдонимы уровня портала имеют приоритет над псевдонимами уровня сервера.

Если существует несколько имён, портал разрешает их в следующем порядке: portal_alias > server_alias > alias > исходное имя инструмента.

Если псевдоним не задан, портал использует исходное имя и описание с вышестоящего сервера.

Пользовательские описания следуют тому же порядку приоритета. Чтобы задать описание, включите description поле у записи в updated_tools или updated_prompts. В ответах API описания уровня сервера возвращаются как server_description а описания на уровне портала возвращаются как portal_description. Если заданы оба описания, описание на уровне портала имеет приоритет над описанием на уровне сервера.

Изменённые инструменты и промпты отображают Изменено метка на панели управления.

Отправьте PUT запрос к обновить портал MCP конечная точка. Включите alias поле для каждого инструмента или подсказки, которые вы хотите переименовать.

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/ai-controls/mcp/portals/%7Bid%7D" \
	--request PUT \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"servers": [
				{
						"server_id": "example-server",
						"updated_tools": [
								{
										"name": "original_tool_name",
										"enabled": true,
										"description": "A clearer description of what this tool does.",
										"alias": "renamed_tool"
								}
						],
						"updated_prompts": [
								{
										"name": "original_prompt_name",
										"enabled": true,
										"description": "An updated description for this prompt.",
										"alias": "renamed_prompt"
								}
						]
				}
		]
	}'

Чтобы задать псевдонимы уровня сервера, которые применяются ко всем порталам, отправьте PUT запрос к обновить MCP-сервер конечную точку с тем же updated_tools и updated_prompts поля.

Чтобы сбросить имя инструмента или промпта к исходному имени, заданному вышестоящим сервером, откройте окно редактирования инструмента или промпта в панели управления и выберите "Reset to server definition." При использовании API не указывайте alias поле из соответствующей записи в updated_tools или updated_prompts.

MCP-клиенты получают псевдоним и описание вместо оригинального имени. Конечные пользователи не видят исходное имя.

Если вы измените псевдоним, пока у пользователя открыт активный сеанс, ему потребуется пройти повторную аутентификацию, чтобы увидеть изменения. См. Управлять сессиями портала для параметров повторной аутентификации.

Все инструменты и промпты, доступные через портал, автоматически получают пространство имён с ID сервера в качестве префикса. Формат такой: {server_id}_{original_name}. Например, инструмент с именем list_issues на сервере с ID github отображается как github_list_issues в портале. Это предотвращает конфликты имён, когда несколько MCP-серверов предоставляют инструменты с одинаковыми именами.

Промпты следуют одному и тому же шаблону. Промпт с именем summarize на сервере с ID github отображается как github_summarize.

Идентификатор сервера, используемый для пространства имён, берётся из ID сервера поле, которое вы задали при добавление MCP-сервера. На шаге 5 процесса настройки вы можете ввести собственный ID сервера или позволить Cloudflare сгенерировать его автоматически.

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

Портал разделяет имена с пространствами имён по первый только символ подчёркивания. Всё, что стоит до первого подчёркивания, это идентификатор сервера, а всё, что после, это имя инструмента или запроса. Поэтому имена инструментов могут содержать символы подчёркивания без риска двусмысленности.

Поскольку разделение происходит по первому символу подчёркивания, сами идентификаторы серверов не могут содержать символы подчёркивания. Если нужен составной идентификатор сервера из нескольких слов, используйте вместо этого дефисы (например, my-server).

Если вы Переименовать инструмент с помощью псевдонима, псевдоним заменяет исходное имя инструмента в формате с пространством имён. Префикс ID сервера по-прежнему применяется.

Например, если вы создали псевдоним для инструмента list_issues к issues на сервере с ID github, имя в формате с пространством имён принимает вид github_issues.

Когда Code Mode активен, портал применяет дополнительное преобразование, чтобы имена инструментов с пространством имён можно было безопасно использовать в качестве идентификаторов JavaScript. Дефисы и точки в имени с пространством имён заменяются на подчёркивания, а имена, начинающиеся с цифры, получают _ префикс, а зарезервированные слова JavaScript получают _ суффикс. Например, сервер с ID my-server и инструмент с именем get-data будет выглядеть как my_server_get_data в песочнице Code Mode.

Эта очистка данных выполняется автоматически. Конечному пользователю не нужно вызывать какие-либо вспомогательные функции при работе с Code Mode.

Если вы создаете клиент MCP с помощью Agents SDK, SDK предоставляет вспомогательные функции для работы с ID серверов и именами инструментов:

• normalizeServerId (экспортировано из agents/mcp/client) приводит указанный вызывающей стороной ID сервера к безопасной строке. Например, "GitHub MCP!" становится "github-mcp". SDK вызывает это автоматически при передаче id опцию в addMcpServer().
• sanitizeToolName (экспортировано из @cloudflare/codemode) преобразует имя инструмента в допустимый идентификатор JavaScript, заменяя дефисы и точки на символы подчёркивания. Это происходит автоматически в контексте Code Mode. Обратитесь к Справочник SDK Code Mode для получения подробностей.

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

Указанные ниже инструменты доступны в любой сессии портала независимо от режима подключения:

Эти инструменты лежат в основе управление сессиями функции, описанные далее в этом руководстве. ИИ-агенты вызывают их автоматически, когда вы просите включить сервер, отключить сервер или вернуться на страницу выбора сервера.

Когда вы подключаетесь с помощью optimize_context параметр запроса портал предоставляет дополнительные инструменты для обнаружения и вызова вышестоящих инструментов:

Когда вы подключаетесь с помощью Code Mode включена, портал заменяет все вышестоящие инструменты двумя инструментами выполнения кода:

См. Справочник SDK Code Mode для сведений о написании кода для этих инструментов.

Помимо панели управления, вы можете управлять порталами MCP-серверов программно с помощью Cloudflare API. В следующих примерах показаны типичные операции.

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/ai-controls/mcp/portals" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/ai-controls/mcp/portals" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "Engineering Portal",
		"hostname": "mcp.example.com",
		"code_mode": "opt_in",
		"secure_web_gateway": false
	}'

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/ai-controls/mcp/servers" \
	--request GET \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/ai-controls/mcp/servers" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN" \
	--json '{
		"name": "GitHub MCP Server",
		"hostname": "https://github-mcp.example.workers.dev/mcp",
		"auth_type": "oauth"
	}'

auth_type поле принимает следующие значения:

auth_credentials поле принимает две формы:

• Необработанный bearer-токен : портал отправляет это значение как Authorization: Bearer <token> заголовок в запросах к вышестоящему MCP-серверу:

  {
    "auth_type": "bearer",
    "auth_credentials": "your-bearer-token"
  }

• Объект пользовательских заголовков, закодированный в формате JSON : для вышестоящих MCP-серверов, которым требуется несколько заголовков или нестандартное имя заголовка:

  {
    "auth_type": "bearer",
    "auth_credentials": "{\"headers\":{\"X-Api-Key\":\"<api-key>\",\"X-Client-Id\":\"<client-id>\"}}"
  }

  Значение auth_credentials должен быть строкой JSON. Разобранный объект должен иметь headers поле, сопоставляющее имена заголовков со строковыми значениями. Портал передаёт все заголовки без изменений вышестоящему серверу MCP.

Чтобы вручную запустить синхронизацию инструментов и промптов с upstream-сервера MCP:

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/ai-controls/mcp/servers/%7Bserver_id%7D/sync" \
	--request POST \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

curl "https://api.cloudflare.com/client/v4/accounts/%7Baccount_id%7D/access/ai-controls/mcp/portals/%7Bid%7D" \
	--request DELETE \
	--header "Authorization: Bearer $CLOUDFLARE_API_TOKEN"

Управлять MCP server portals можно с помощью Провайдер Terraform для Cloudflare ↗. Используйте cloudflare_zero_trust_access_mcp_server_portal ресурс, чтобы создавать и настраивать порталы программно.

В следующем примере создаётся портал сервера MCP с записью CNAME:

# Create the MCP server portal
resource "cloudflare_zero_trust_access_mcp_server_portal" "example" {
  account_id = var.cloudflare_account_id
  name       = "Engineering Portal"
  hostname   = "mcp.example.com"
}

# Required: Create the CNAME record for the portal hostname
resource "cloudflare_dns_record" "mcp_portal" {
  zone_id = var.cloudflare_zone_id
  name    = "mcp"
  content = "gateway.agents.cloudflare.com"
  type    = "CNAME"
  proxied = true
}

Полный список поддерживаемых аргументов ресурса см. в Документация провайдера Terraform ↗.

Code Mode снижает использование контекстного окна, заменяя определения вышестоящих инструментов двумя инструментами для поиска и выполнения кода. Подключенный ИИ-агент пишет JavaScript-код, который вызывает типизированные codemode.* методы. Сгенерированный код выполняется в изолированной Dynamic Worker среде. Учётные данные аутентификации и переменные окружения остаются вне контекста модели.

Code Mode полезен для порталов с большим количеством MCP server или инструментов. Использование context window остается неизменным по мере добавления в портал новых инструментов.

У каждого портала есть политика Code Mode. Политика по умолчанию: Opt-in.

Используйте Opt-in или Включено по умолчанию если некоторые клиенты используют собственную реализацию Code Mode. Эти политики позволяют клиентам избегать вложенного выполнения кода.

Порталы MCP не поддерживают вышестоящие MCP-серверы с включённым собственным Code Mode. При добавлении сервера в портал подключайтесь к версии сервера, которая возвращает полный список инструментов. Если вышестоящий сервер использует собственный Code Mode, воспользуйтесь механизмом отказа сервера, если он доступен. В противном случае рассмотрите возможность отключения Code Mode на вашем портале MCP.

allow_code_mode Поле API считается устаревшим. Используйте code_mode для новых интеграций.

Политика портала определяет, требуется ли клиенту MCP параметр запроса. Для Opt-in, добавьте ?codemode=search_and_execute к URL портала. Для Включено по умолчанию, клиенты могут добавить ?codemode=off взамен.

Например, Opt-in портал по адресу https://<subdomain>.<domain>/mcp использует следующий URL-адрес:

https://<subdomain>.<domain>/mcp?codemode=search_and_execute

Для MCP-клиентов с файлами конфигурации сервера используйте URL портала с параметром строки запроса:

{
	"mcpServers": {
		"example-portal": {
			"command": "npx",
			"args": [
				"-y",
				"mcp-remote@latest",
				"https://<subdomain>.<domain>/mcp?codemode=search_and_execute"
			]
		}
	}
}

Когда включён Code Mode, портал анонсирует portal_codemode_search и portal_codemode_execute. ИИ-агент может обнаруживать инструменты и объединять несколько вызовов инструментов в одном выполнении.

Дополнительные сведения о разработке с использованием Code Mode см. в Справочник SDK Code Mode.

Когда включена маршрутизация Gateway, вызовы к серверам MCP, защищённым вашим порталом сервера MCP, направляются через Cloudflare Gateway. Из-за этого трафик portal отображается в Журналы HTTP Gateway наряду с остальным HTTP трафиком вашей организации. После этого вы можете создать Политики Data Loss Prevention (DLP) чтобы обнаруживать и блокировать отправку конфиденциальных данных на ваши вышестоящие MCP-серверы.

Когда пользователь вызывает инструмент через портал, портал проксирует запрос к вышестоящему MCP-серверу. При включённой маршрутизации Gateway этот исходящий запрос проходит через Cloudflare Gateway, прежде чем достичь вышестоящего сервера. Gateway анализирует трафик и применяет все подходящие политики HTTP, включая сканирование DLP.

Поскольку трафик портала проходит через Gateway, для него также учитываются Политики Egress Gateway. Это означает, что исходящие запросы к вышестоящим MCP-серверам будут отправляться с ваших выделенных исходящих IP-адресов или диапазонов IP-адресов Gateway, а не с обычных IP-адресов Cloudflare. Если ваши вышестоящие MCP-серверы ограничивают входящий трафик по IP-адресу источника (например, для VPN или корпоративного диапазона IP-адресов), вы можете использовать политики исходящего трафика, чтобы трафик портала поступал с предсказуемого набора IP-адресов.

Для проверки DLP требуется, чтобы Gateway расшифровывала трафик TLS. Для трафика портала Gateway расшифровывает и проверяет полезную нагрузку автоматически, поэтому включать настройку на уровне аккаунта Расшифровка TLS параметр. Поскольку портал завершает соединение от MCP-клиента и повторно инициирует запрос через Gateway, Gateway расшифровывает трафик портала независимо от того, включён ли глобальный параметр расшифровки TLS.

Это автоматическое расшифрование применяется только к трафику, который проходит через портал. Чтобы проверить MCP-трафик, не проходящий через портал, например агент на устройство, на котором запущен клиент WARP прямого подключения к upstream-серверу MCP необходимо включить Расшифровка TLS так же, как и для любого другого Политика HTTP.

Маршрутизация Gateway поддерживает Streamable HTTP ↗ только подключения. Если upstream-сервер MCP настроен с конечной точкой Server-Sent Events (SSE), то есть URL-адресом, заканчивающимся на /sse), портал автоматически попытается подключиться через Streamable HTTP. Если вышестоящий сервер не поддерживает Streamable HTTP, при включенной маршрутизации Gateway подключение завершится ошибкой.

Чтобы направить трафик портала сервера MCP через Gateway:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.
2. Найдите портал, который вы хотите настроить, а затем выберите три точки > Изменить.
3. В разделе Основная информация, включите Направьте трафик через Cloudflare Gateway.
4. Выберите Save.

Теперь трафик портала будет отображаться в вашем Журналы HTTP Gateway. Чтобы применить сканирование DLP, создать политику HTTP Gateway.

Чтобы сканировать трафик на наличие конфиденциальных данных, создать политику HTTP Gateway который соответствует одновременно серверу MCP и предопределённому или пользовательскому Профиль DLP.

Политики HTTP Gateway для трафика MCP-портала должны явно указывать вышестоящий MCP-сервер в качестве цели. Убедитесь, что ваша политика соответствует имени хоста вышестоящего MCP-сервера (например, example-mcp-server.example.workers.dev) а не URL-адрес портала (<subdomain>.<domain>).

Например, следующая политика блокирует трафик, содержащий учётные данные и секреты или финансовая информация:

Когда вызов инструмента совпадает с политикой Block DLP, Gateway блокирует его, и портал возвращает MCP-клиенту ошибку о блокировке вместо выполнения вызова. Это применяется в обоих направлениях:

• Запросы вызова инструмента: Если данные, которые агент отправляет инструменту, соответствуют профилю DLP, Gateway блокирует исходящий запрос, и агент получает ошибку о том, что запрос был заблокирован.
• Ответы вызова инструмента: Если данные, которые возвращает вышестоящий сервер, соответствуют профилю DLP, Gateway блокирует ответ, и портал возвращает ошибку вместо совпавшего содержимого.

Агент может повторить запрос, но он будет по-прежнему блокироваться до тех пор, пока содержимое не перестанет соответствовать политике.

• DLP Профили AI-промптов не применяются к трафику портала MCP-сервера. Профили AI Prompt рассчитаны на конкретные пути API веб-клиента и не соответствуют формату протокола MCP. Используйте вместо них стандартные профили DLP.
• Транспорт SSE не поддерживается через Gateway. Если ваш вышестоящий MCP-сервер поддерживает только SSE, маршрутизация Gateway для этого сервера работать не будет.
• Фоновая синхронизация инструментов и подсказок не проходит через Gateway. Проверяются только пользовательские запросы в режиме реального времени.

Пользователи могут подключаться к вашему серверу MCP, работающему по адресу https://<subdomain>.<domain>/mcp с помощью Workers AI Playground ↗, MCP inspector ↗, или другие MCP-клиенты которые поддерживают удалённые серверы MCP.

Чтобы протестировать в Workers AI Playground:

1. Перейдите в Workers AI Playground ↗.
2. В разделе MCP-серверы, введите https://<subdomain>.<domain>/mcp для URL портала.
3. Выберите Подключить.
4. Во всплывающем окне войдите через поставщика идентификации, настроенного для Cloudflare Access.
5. Всплывающее окно покажет список серверов MCP в портале, которые требуют аутентификации. Для каждого из этих серверов MCP выберите Подключить и следуйте подсказкам при входе.
6. Выберите Готово чтобы завершить процесс аутентификации портала.

Workers AI Playground покажет Подключено статус и выводит список доступных инструментов. Теперь вы можете попросить ИИ-модель выполнить задачу с помощью доступного инструмента. Запросы к MCP-серверу будут отображаться в вашем логи портала.

Для MCP-клиентов с файлами конфигурации сервера рекомендуем использовать npx команду с mcp-remote@latest аргумент:

{
	"mcpServers": {
		"example-mcp-server": {
			"command": "npx",
			"args": [
				"-y",
				"mcp-remote@latest",
				"https://<subdomain>.<domain>.com/mcp"
			]
		}
	}
}

Мы не рекомендуем использовать serverURL параметр, поскольку это может вызвать проблемы при создании сеанса портала и управлении им.

Когда пользователи посещают домен портала (https://<subdomain>.<domain>/) в браузере, портал отображает домашнюю страницу с данными подключения и инструкциями по настройке.

На домашней странице отображается:

• Имя портала и брендинг вашей организации (если настроено в Cloudflare Access)
• URL-адрес конечной точки MCP с кнопкой копирования
• Инструкции по подключению для отдельных клиентов, включая Claude Desktop, Workers AI Playground, OpenCode, Windsurf и другие MCP-клиенты, с путями к файлам для конкретной ОС

Аутентифицированные пользователи видят свой адрес электронной почты и Выйти на панели сеанса. Неаутентифицированные пользователи всё равно могут просматривать домашнюю страницу и инструкции по подключению.

Чтобы завершить сеанс портала, выберите Выйти из домашняя страница портала (https://<subdomain>.<domain>/). Процесс выхода из системы:

1. Отзывает все разрешения OAuth уровня портала, выданные вашему пользователю.
2. Удаляет все состояния OAuth вышестоящих MCP-серверов, связанные с вашей сессией.
3. Перенаправления через выход из Cloudflare Access.

После выхода портал показывает страницу подтверждения со сводкой отозванных сессий. Чтобы подключиться снова, откройте главную страницу портала и пройдите аутентификацию ещё раз.

Вы можете подключиться к порталу MCP с помощью Сервисный токен Access для доступа между машинами. Токены служб обходят процесс OAuth на основе браузера и выполняют аутентификацию с помощью CF-Access-Client-Id и CF-Access-Client-Secret заголовки.

Сессия токена службы авторизуется дважды: один раз по URL-адресу портала и один раз для каждого вышестоящего MCP-сервера, к которому она пытается получить доступ через портал. Обе проверки требуют совпадающего политика Service Auth.

Если у связанного сервера MCP нет политики Service Auth, соответствующей токену, этот сервер скрывается из списка инструментов бота.

1. Создать токен службы в вашем аккаунте Zero Trust.
2. Откройте приложение Access в портале и добавьте политику Service Auth, включающую сервисный токен.
3. Для каждого вышестоящего MCP-сервера, к которому должен обращаться бот:
   1. Откройте приложение Access сервера и добавьте политику Service Auth, включающую тот же сервисный токен.
   2. Откройте портал и отредактируйте сервер. Включите Требовать аутентификации пользователя отключён, чтобы портал использовал учётные данные администратора для этого сервера.
4. Подключитесь из своего MCP-клиента, используя заголовки токена службы.

Для CLI-клиента задайте заголовки напрямую:

curl https://<subdomain>.<domain>/mcp \
  -H "CF-Access-Client-Id: <CLIENT_ID>" \
  -H "CF-Access-Client-Secret: <CLIENT_SECRET>"

Для mcp-remote, передайте заголовки с помощью --header:

{
	"mcpServers": {
		"example-portal": {
			"command": "npx",
			"args": [
				"-y",
				"mcp-remote@latest",
				"https://<subdomain>.<domain>/mcp",
				"--header",
				"CF-Access-Client-Id: <CLIENT_ID>",
				"--header",
				"CF-Access-Client-Secret: <CLIENT_SECRET>"
			]
		}
	}
}

Порталы MCP-сервера требуют процесса аутентификации через браузер. Аутентификация устройства (получение идентификационных данных из Cloudflare One Client без перенаправления в браузер) в настоящее время не поддерживается для MCP-порталов. При первом подключении пользователям необходимо пройти вход через Access в браузере.

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

Чтобы использовать оптимизацию контекста, добавьте optimize_context параметр запроса к URL-адресу вашего портала при подключении из MCP-клиента.

minimize_tools опция удаляет описания инструментов и входные схемы у всех вышестоящих инструментов, оставляя только их названия. Портал предоставляет специальный query инструмент, который агенты используют для поиска и получения полных определений инструментов по запросу. Агенты могут обнаруживать инструменты, не загружая все определения заранее.

Этот параметр позволяет сократить использование токенов до 5 раз, хотя запрос определений инструментов перед использованием добавляет небольшие накладные расходы.

Чтобы подключиться с помощью minimize_tools, используйте следующий URL-адрес портала:

https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools

Для MCP-клиентов с файлами конфигурации сервера:

{
	"mcpServers": {
		"example-portal": {
			"command": "npx",
			"args": [
				"-y",
				"mcp-remote@latest",
				"https://<subdomain>.<domain>/mcp?optimize_context=minimize_tools"
			]
		}
	}
}

search_and_execute скрывает все вышестоящие инструменты и предоставляет агенту только два инструмента: query и execute. query инструмент выполняет поиск и получает определения инструментов. execute инструмент запускает вышестоящие инструменты. Сгенерированный код выполняется в изолированной Dynamic Worker среде, что позволяет не передавать учётные данные аутентификации и переменные окружения в контекст модели.

Этот параметр снижает начальную стоимость токенов для инструментов портала до небольшой постоянной величины независимо от количества доступных инструментов. Однако агент при этом полностью полагается на query чтобы обнаружить инструменты, прежде чем сможет их вызывать.

Чтобы подключиться с помощью search_and_execute, используйте следующий URL-адрес портала:

https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute

Для MCP-клиентов с файлами конфигурации сервера:

{
	"mcpServers": {
		"example-portal": {
			"command": "npx",
			"args": [
				"-y",
				"mcp-remote@latest",
				"https://<subdomain>.<domain>/mcp?optimize_context=search_and_execute"
			]
		}
	}
}

Дополнительные сведения о шаблоне Code Mode, лежащем в основе search_and_execute, см. Code Mode.

После подключения к порталу пользователи могут управлять сессиями вышестоящих серверов MCP, не покидая клиент MCP. Портал использует MCP elicitations ↗ для отображения страницы выбора сервера, на которой можно включать и отключать серверы, выходить из отдельных серверов и проходить повторную аутентификацию.

Чтобы управлять подключениями к серверам во время активной сессии, попросите своего ИИ-агента вернуть вас на страницу выбора сервера. Например, отправьте агенту следующий промпт:

Вернуться на страницу выбора сервера.

Портал возвращает URL-адрес авторизации. Откройте этот URL-адрес в веб-браузере, чтобы перейти на страницу выбора сервера:

https://<subdomain>.<domain>/authorize?elicitationId=<ELICITATION_ID>

На этой странице можно:

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

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

Включите wiki-сервер.

Отключить мой сервер Jira.

Портал переключает сервер и сразу же обновляет список активных инструментов. Отключение сервера удаляет его инструменты из сессии, что уменьшает использование контекстного окна.

Когда истекает срок действия токена вышестоящего MCP-сервера, портал предлагает переавторизоваться прямо в MCP-клиенте. Откройте указанный URL-адрес в браузере и завершите вход, чтобы восстановить сеанс.

Если клиент MCP не показывает запрос на повторную аутентификацию, можно вручную очистить кэшированные учетные данные:

rm -rf ~/.mcp-auth

Очистив учётные данные, подключитесь к порталу заново из своего MCP-клиента.

Когда администратор добавляет новый вышестоящий MCP-сервер в портал, портал автоматически предлагает подключённым пользователям авторизовать новый сервер. Портал объединяет изменения администратора и один раз перенаправляет вас на авторизацию, вместо того чтобы прерывать работу при каждом обновлении отдельного сервера.

Журналы портала позволяют отслеживать активность пользователей через портал MCP-сервера. Просматривать журналы можно как по отдельному порталу, так и по отдельному серверу.

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Контроль доступа > Элементы управления ИИ.
2. Найдите портал или сервер, журналы которого вы хотите просмотреть, а затем выберите три точки > Изменить.
3. Выберите Журналы.

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

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

Порталы MCP-сервера имеют следующие известные ограничения:

• Поддерживаются только удалённые HTTP-серверы MCP. MCP-серверы, которые используют только транспорт stdio ↗ (например, github/github-mcp-server) не предоставляют удалённую конечную точку HTTP и не могут быть добавлены на портал MCP-сервера. Чтобы использовать сервер, работающий только через stdio, необходимо разместить его самостоятельно за конечной точкой HTTP и выполнять аутентификацию с помощью bearer-токен или пользовательские заголовки.
• Некоторые серверы MCP блокируют клиенты, работающие через прокси. Некоторые серверы MCP отклоняют запросы от клиентов на основе прокси, таких как порталы серверов MCP, возвращая 403 ошибка на конечной точке регистрации. Такие серверы несовместимы с порталами MCP-сервера, пока эти провайдеры не добавят Cloudflare в число поддерживаемых MCP-клиентов.
• Возможности Manual OAuth фиксируются при первой авторизации пользователя. Серверы, настроенные с ручные учётные данные OAuth остаются в Ожидание статус, пока пользователь не завершит процесс OAuth с вышестоящим сервером. Cloudflare сохраняет инструменты и подсказки, полученные во время этого подключения. Фоновая и ручная синхронизация возможностей их не обновляет.
• OAuth-токены администратора могут истекать незаметно. Учётные данные администратора, используемые для аутентифицировать сервер MCP подчиняется политике истечения срока действия токена вышестоящего провайдера. Когда срок действия токена истекает, статус сервера меняется на Ошибка или Требуется синхронизация и сервер не будет отображаться в портале для конечных пользователей. Администраторы не получают уведомления об этом. Периодически проверяйте статус сервера и пройти повторную аутентификацию серверов, которые показывают ошибку.
• Каждый портал поддерживает до 40 MCP-серверов. Если требуется объединить более 40 серверов в одном портале, обратитесь в команду по работе с аккаунтом Cloudflare, чтобы запросить более высокий лимит. По мере приближения к лимиту панель управления показывает предупреждение.

MCP-серверы используют выделенный тип приложения Access (mcp) который не поддерживает следующие функции политики Access, когда сервер авторизован через портал.

• Независимая MFA : Пользователям не будет предложено пройти MFA через Cloudflare Access при авторизации сервера, независимо от того, включено ли глобальное применение MFA или назначена ли серверу политика MFA.
• Обоснование цели : Пользователям не будет предложено указать обоснование цели при авторизации сервера.
• Временная аутентификация : Пользователям не будет предложено запросить доступ, а согласующие не будут получать запросы на согласование, когда пользователь авторизует сервер.

Эти ограничения относятся только к серверам, авторизация которых выполняется через портал. Такие селекторы политик Access, как Emails, Groups, Country и Device Posture Checks, будут применяться.

Независимая MFA, обоснование цели и временная аутентификация будут применяться для серверов, не авторизованных через портал.

1. И у портала, и у сервера MCP должна быть прикреплённая политика Access. Убедитесь, что у всех серверов MCP, назначенных порталу, есть собственная связанная политика.
2. Срок действия аутентификации администратора сервера, возможно, истёк. Убедитесь, что статус сервера это Готово. Если статус отображается как Ошибка или Требуется синхронизация, заново аутентифицировать сервер.

1. Убедитесь, что порталу назначена политика Access.
2. Убедитесь, что к URL портала не применены никакие Workers, Page Rules, пользовательское имя хоста определений или любой другой конфигурации, которая может помешать его способности подключаться к MCP-клиенту.

A 522 ошибка означает, что Cloudflare не может подключиться к источнику портала. Как правило, это означает, что запись DNS для имени хоста портала отсутствует или настроена неверно.

1. Убедитесь, что для поддомена вашего портала существует запись CNAME, указывающая на gateway.agents.cloudflare.com.
2. Убедитесь, что запись CNAME имеет Статус прокси включена в Cloudflare DNS.
3. Если вы создали портал с помощью API или Провайдер Terraform, вам необходимо создать DNS-запись отдельно. В отличие от панели управления, API и провайдер Terraform не создают DNS-записи автоматически.

Waiting статус означает, что Cloudflare пытается подключиться к вышестоящему MCP-серверу и получить его инструменты и подсказки. Если сервер остаётся в этом статусе:

1. Убедитесь, что URL upstream-сервера MCP указан верно и сервер доступен.
2. Проверьте, что вышестоящий сервер поддерживает Streamable HTTP ↗ или транспорт SSE. Портал автоматически попробует несколько стратегий подключения.
3. Если сервер требует аутентификации, убедитесь, что учётные данные администратора действительны, повторная аутентификация сервера.
4. Выберите три точки > Возможности синхронизации чтобы вручную повторить попытку подключения.

A Stale статус означает, что учётные данные администратора для сервера не удалось обновить во время последней попытки синхронизации. Инструменты сервера могут по-прежнему работать для пользователей с собственными токенами OAuth (серверы с Требовать аутентификации пользователя включена), но учётные данные администратора необходимо обновить.

Чтобы устранить это, заново аутентифицировать сервер с действительными учётными данными администратора.

1. Если сервер использует OAuth для каждого пользователя (Требовать аутентификации пользователя включён), возможно, истёк срок действия OAuth-токена пользователя. Попросите пользователя заново аутентифицировать сервер из своего MCP-клиента.
2. Если сервер использует учётные данные администратора, проверьте статус сервера. Статус Ошибка или Требуется синхронизация означает, что учётные данные администратора необходимо обновить.
3. Если пользователь недавно изменил разрешения в вышестоящей службе (например, отозвал области действия OAuth), ему потребуется пройти повторную аутентификацию.

Ошибки, такие как invalid_redirect_uri, invalid_client_metadata, или Redirect URI not allowed означают, что вышестоящий MCP-сервер отклонил URL обратного вызова, зарегистрированный порталом в ходе OAuth-потока. Обратитесь к Вышестоящий URL обратного вызова OAuth для справки о том, как определяется callback URL.

1. По умолчанию вышестоящий провайдер должен внести в список разрешенных (allowlist) https://<your-portal-hostname>/servers-callback как redirect URI (например, https://my-portal.example.com/servers-callback). Провайдеры OAuth обычно требуют точного совпадения полного URI, включая путь. Если вы не управляете allowlist, обратитесь к поставщику вышестоящего MCP-сервера.
2. Если портал настроен на использование общий URL обратного вызова Cloudflare, вместо этого вышестоящий провайдер должен внести в список разрешённых https://oauth-callbacks.cloudflareaccess.com/cdn-cgi/access/outbound-oauth-callback.

1. Убедитесь, что upstream-сервер MCP поддерживает транспорт Streamable HTTP. Транспорт SSE через Gateway не поддерживается.
2. Если URL-адрес вышестоящего сервера заканчивается на /sse, портал автоматически пытается подключиться с использованием Streamable HTTP по /mcp путь вместо этого. Если сервер не поддерживает такой путь, подключение завершится ошибкой.
3. Проверьте Журналы HTTP Gateway для событий блокировки DLP. Если политика DLP блокирует трафик, портал возвращает клиенту MCP ошибку с указанием идентификатора правила DLP.

1. Убедитесь, что используете последнюю версию mcp-remote. Выполните npx -y mcp-remote@latest чтобы обновить.
2. Используйте command и args формате в конфигурации вашего MCP-клиента, а не serverURL параметр. serverURL параметр может вызвать проблемы при создании сеанса портала.
3. Если аутентификация постоянно завершается ошибкой, очистите кешированные учётные данные, выполнив rm -rf ~/.mcp-auth и повторного подключения.

На главной странице портала отображаются имя вашей организации Access и её брендинг. Если отображаемое имя указано неверно:

1. В Панель управления Cloudflare ↗, перейдите в Zero Trust > Настройки > Общее > Название команды.
2. Обновите имя своей команды. Изменение вступит в силу при следующем посещении пользователем домашней страницы портала.