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

portály serveru MCP

Portál pro servery MCP centralizuje více Servery Model Context Protocol (MCP) ↗ do jediného HTTP endpointu.

Tento návod vysvětluje, jak přidat MCP servery do Cloudflare Access, vytvořit MCP portál s vlastními nástroji a zásadami a připojit uživatele k portálu pomocí MCP klienta.

Portály serveru MCP poskytují následující možnosti:

• Zjednodušený přístup k více serverům MCP: Portály serveru MCP podporují jak neověřené servery MCP, tak servery MCP zabezpečené pomocí OAuth (například prostřednictvím Access for SaaS nebo poskytovatel OAuth třetí strany). Uživatelé se přihlašují na adresu URL portálu přes Cloudflare Access a jsou vyzváni k samostatnému ověření u každého serveru, který vyžaduje OAuth.
• Kompatibilita s protokolem MCP: Portál podporuje bezstavové MCP 2026-07-28 a dřívější klienty a servery Streamable HTTP z roku 2025. Portál pro každé připojení sám vybere podporovaný protokol, aniž by bylo nutné nastavovat protokol ručně.
• Přizpůsobené nástroje pro jednotlivé portály: Správci mohou přizpůsobit portál MCP konkrétnímu případu použití tím, že zvolí konkrétní nástroje a šablony promptů, které chtějí uživatelům zpřístupnit prostřednictvím portálu. Uživatelé tak získají přístup k vybrané sadě nástrojů a promptů: čím méně externího kontextu je modelu AI vystaveno, tím lépe obvykle model AI odpovídá.
• Aliasy nástrojů a promptů: Správci mohou přejmenovat nástroje a prompty a upravovat jejich popisy na úrovni portálu nebo serveru, aniž byste upravovali nadřazený MCP server. Aliasy pomáhají koncovým uživatelům najít správný nástroj a AI agentům vybrat ten správný.
• Optimalizace kontextu: Portály podporují možnosti parametrů dotazu, které snižují využití kontextového okna tím, že minimalizují nebo skrývají definice nástrojů. Podívejte se na Optimalizace kontextu s podrobnostmi.
• Podpora klientů mimo prohlížeč: Klienti MCP se k portálu ověřují pomocí standardního postupu OAuth 2.0 Authorization Code Flow prostřednictvím managed OAuth. Tato konfigurace Managed OAuth platí pro aplikaci Access portálu. Je oddělená od upstream OAuth, které používají jednotlivé servery MCP v portálu. Klienti bez prohlížeče dostávají 401 odpověď s WWW-Authenticate hlavičku odkazující na OAuth discovery endpointy Access, místo přesměrování prohlížeče. Připojit se můžete také pomocí Access service tokens pro komunikaci typu stroj-stroj.
• Code Mode: Code Mode sloučí všechny upstream nástroje do dvou nástrojů pro vyhledávání a spouštění kódu. AI agent píše JavaScript, který pro každý nástroj volá typované metody. Kód běží v izolovaném Dynamický Worker prostředí. Administrátoři mohou nastavit, zda je Code Mode nedostupný, volitelný, zapnutý ve výchozím nastavení, nebo povinný. Podrobnosti najdete v Code Mode pro pokyny ke konfiguraci a připojení.
• Observabilita: Jakmile je AI agent uživatele připojen k portálu, Cloudflare Access zaznamenává jednotlivé požadavky provedené pomocí nástrojů v portálu. Provoz portálu můžete volitelně směrovat přes Cloudflare Gateway pro podrobnější protokolování HTTP a kontrolu ochrany před únikem dat (DLP).

Následující diagram znázorňuje, jak požadavky procházejí portálem serveru MCP.

1. Klient MCP se připojí k adrese URL portálu a obdrží 401 odpověď s metadaty pro zjišťování OAuth.
2. Uživatel se ověří přes Cloudflare Access pomocí svého poskytovatele identity nebo použije token služby hlaviček.
3. Access ověří identitu uživatele a portál vrátí nástroje dostupné z povolených upstream serverů.
4. Když uživatel zavolá nástroj, portál identifikuje cílový server podle namespace nástroje, připojí příslušné přihlašovací údaje a požadavek proxíruje. Pokud Směrování Gateway je zapnuto, požadavek prochází přes Cloudflare Gateway kvůli protokolování HTTP a kontrole DLP.
5. Upstream server zpracuje požadavek a vrátí odpověď stejnou cestou.

U serverů, které používají automatickou registraci OAuth, probíhá synchronizace nástrojů a promptů na pozadí přibližně každé dvě hodiny pomocí přihlašovacích údajů správce. Tato synchronizace se připojuje přímo k upstream serverům a neprochází přes Gateway.

Portál přijímá stateless MCP 2026-07-28 ↗ a dřívější klienty Streamable HTTP z roku 2025 na jejich /mcp endpoint. Portál vybírá protokol z každého požadavku. Verzi protokolu není třeba nastavovat.

Portál se připojuje k upstreamovým serverům MCP pomocí Streamable HTTP ↗ nebo SSE ↗ transport. U serverů se Streamable HTTP portál kontroluje MCP 2026-07-28 podporu a pokud je k dispozici, použije bezstavový protokol. Pokud jej upstream server nepodporuje, portál se v rámci stejného připojení vrátí k handshaku z roku 2025. Připojení SSE vždy používají starší protokol.

Výběr protokolu na straně klienta a upstream serveru je nezávislý. Klient verze 2025 se tak může přes portál připojit k bezstavovému upstream serveru. Bezstavový klient se může připojit i ke staršímu upstream serveru.

Není nutné určovat, jaký transport váš upstream server používá. Portál automaticky detekuje správný transport tím, že postupně vyzkouší několik strategií připojení:

Pokud pokus o připojení vrátí 404, 405, nebo 406 chyby portál přejde na další strategii. Všechny ostatní chyby pokus o připojení zastaví.

Každý portál zpřístupňuje klientům MCP následující vestavěné nástroje navíc k nástrojům nadřazeného serveru:

Když optimalizace kontextu je zapnuto, v závislosti na režimu se zpřístupní další nástroje:

MCP 2026-07-28 požadavky jsou bezstavové a nevytvářejí relaci protokolu MCP. Portál si pro autorizační grant uživatele uchovává stav ověření, výběru serveru a nadřazeného OAuth.

Starší klienti z roku 2025 vytvářejí relaci, která přetrvává, dokud se uživatel neodpojí nebo dokud relace nevyprší po 24 hodinách nečinnosti.

Uživatelé mohou jednotlivé servery zapínat a vypínat, aniž by se museli odpojit. U bezstavových požadavků se přepínače serverů uplatní na každý požadavek, který používá stejný autorizační grant portálu. U starších klientů platí přepínače pouze pro danou relaci MCP. Přepínače neovlivňují ostatní uživatele.

Portály MCP serverů se dříve označovaly jako Agents Gateway v některých kontextech. Cesty API, prostředky Terraformu a interní zdrojové kódy mohou stále používat agents_gateway nebo agw předpony. Název produktu je portály serveru MCP a navigace v dashboardu je Ovládací prvky AI.

• aktivní doména na Cloudflare
• Doména používá buď plné nastavení nebo částečné (CNAME) nastavení
• poskytovatel identity nakonfigurováno v Cloudflare Zero Trust

Přidejte jednotlivé MCP servery do Cloudflare Access a získáte nad nimi centralizovanou správu.

Chcete-li přidat server MCP:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Ovládací prvky AI.

2. Přejděte na MCP servery kartě.

3. Vyberte Přidejte server MCP.

4. Zadejte libovolný název serveru.

5. (Volitelné) Zadejte vlastní řetězec pro ID serveru.

6. V HTTP URL, zadejte úplnou adresu URL svého serveru MCP. Pokud chcete například přidat MCP server Cloudflare Documentation ↗, zadejte https://docs.mcp.cloudflare.com/mcp.

7. Přidejte Zásady Access k zobrazení nebo skrytí serveru v portál serveru MCP. Odkaz na server MCP se v portálu zobrazí pouze uživatelům, kteří vyhovují zásadě Allow. Uživatelé, kteří zásadou Allow neprojdou, tento server v žádném portálu neuvidí.

8. Vyberte Uložit a připojit server.

9. Pokud MCP server podporuje OAuth, budete přesměrováni k přihlášení u svého poskytovatele OAuth. Přihlásit se můžete k libovolnému účtu na daném MCP serveru. Účet použitý k ověření bude sloužit jako přihlašovací údaje správce pro tento MCP server. Můžete nakonfigurovat portál MCP k použití tohoto přihlašovacího údaje správce k vytváření požadavků.

Cloudflare Access ověří připojení serveru a načte seznam zdrojů, promptů a nástrojů. Jakmile se server úspěšně připojí, stav serveru se změní na Připraveno. Nyní můžete server MCP přidat do portál serveru MCP.

Ruční přihlašovací údaje OAuth použijte, pokud upstream poskytovatel nepodporuje OAuth Dynamic Client Registration ↗. Tento tok používá aplikaci OAuth, kterou zaregistrujete u upstream poskytovatele.

Dashboard používá sdílená callback URL Cloudflare při přepnutí serveru z automatických přihlašovacích údajů na ruční:

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

Vždy zaregistrujte přesměrovací URI zobrazené v dashboardu. Poskytovatelé OAuth obvykle vyžadují přesnou shodu URI.

Cloudflare ukládá client secret v zašifrované podobě a nevrací ho prostřednictvím dashboardu ani API. Při úpravě serveru ponechte Client secret prázdné, pokud chcete zachovat stávající hodnotu. Chcete-li tajný klíč (secret) obměnit, vytvořte nebo aktivujte náhradu u upstream poskytovatele, zadejte novou hodnotu a uložte server.

Ruční přihlašovací údaje vyžadují ověření pro jednotlivé uživatele. Ponechte Vyžadovat ověření uživatele povoleno při přidání serveru do portálu. Server zůstává ve stavu Čekání stavu, dokud první uživatel nedokončí upstream OAuth. Cloudflare poté načte možnosti serveru a změní jeho stav na Připraveno.

MCP Apps ↗ : nástroje, které ve svém popisu deklarují prostředek UI, budou po úspěšném připojení k serveru MCP rovněž k dispozici. Seznam klientů MCP, které podporují MCP Apps, najdete v Matice podpory rozšíření ↗.

Stav serveru MCP udává stav synchronizace serveru MCP s Cloudflare Access.

Když je server MCP ve stavu Chyba nebo Vyžadována synchronizace stavu, Cloudflare Access zobrazí strukturované informace, které vám pomohou problém diagnostikovat. V dashboardu najeďte myší na stav serveru a zobrazí se chybová zpráva, kategorie chyby (upstream nebo připojení), stavový kód HTTP a kód chyby protokolu MCP (pokud je k dispozici). Stejné podrobnosti vrací i API jako error_details objekt:

Mezi časté příčiny chyb serveru patří vypršelé přihlašovací údaje OAuth, nedostupné adresy URL serveru a chybné konfigurace upstream serveru. Pokud je typ chyby upstream_error, zkontrolujte chybové kódy HTTP a MCP a zjistěte problém na upstream serveru. Pokud je typ unreachable, ověřte, že je URL serveru správná a dostupná.

Chcete-li znovu ověřit server MCP v Cloudflare Access:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Ovládací prvky AI.
2. Přejděte na MCP servery kartě.
3. Vyberte server, u kterého chcete provést opětovné ověření, a poté vyberte Úprava.
4. Vyberte Ověření serveru.

Budete přesměrováni k přihlášení u vašeho poskytovatele OAuth. Účet použitý k ověření bude sloužit jako nové přihlašovací údaje správce pro tento server MCP.

U serverů, které používají automatickou registraci OAuth, Cloudflare Access synchronizuje nástroje a prompty přibližně každé dvě hodiny. Během synchronizace se Cloudflare připojuje k vašemu serveru MCP pomocí přihlašovací údaje správce a načte aktuální seznam nástrojů a promptů. Pokud platnost přístupového tokenu OAuth správcovských přihlašovacích údajů vypršela, Cloudflare jej před připojením automaticky obnoví pomocí uloženého obnovovacího tokenu.

Chcete-li ručně obnovit server MCP v Zero Trust:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Ovládací prvky AI.
2. Přejděte na MCP servery kartu a najděte server, který chcete obnovit.
3. Vyberte tři tečky > Možnosti synchronizace.

Stránka serveru MCP zobrazí aktualizovaný seznam nástrojů a promptů. Nové nástroje a prompty se v portálu serveru MCP automaticky povolí.

Synchronizaci můžete také spustit prostřednictvím API. Endpoint pro synchronizaci po jejím dokončení vrátí aktuální stav serveru, včetně aktualizovaného stav serveru, počet nástrojů a podrobnosti chyby pokud synchronizace selhala.

Když uživatel autorizuje upstream server MCP, který vyžaduje OAuth pro jednotlivé uživatele, portál za uživatele provede s upstream serverem tok autorizačního kódu OAuth. V rámci tohoto toku portál zaregistruje adresu URL pro zpětné volání (redirect_uri) s upstream serverem. Upstream server po autorizaci přístupu uživatele přesměruje na tuto adresu URL.

Portál ve výchozím nastavení používá callback URL na doméně vašeho portálu:

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

Přidejte tuto adresu URL na seznam povolených jako přesměrovací URI u nadřazeného poskytovatele OAuth. Poskytovatelé OAuth obvykle vyžadují přesnou shodu celého URI včetně cesty.

Pokud jste pro portál zapnuli sdílenou callback URL, portál místo toho používá URL adresu vlastněnou Cloudflare:

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

Sdílenou callback URL použijte v případě, že upstream dodavatelé povolují ve svém allowlistu jen malý počet přesměrovacích URI, nebo pokud chcete napříč více portály používat jedinou URL ve vlastnictví Cloudflare. Sdílená callback URL se použije pouze tehdy, když je pro daný portál výslovně zapnutá.

Chcete-li vytvořit portál serveru MCP:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Ovládací prvky AI.

2. Vyberte Přidání portálu serveru MCP.

3. Zadejte libovolný název portálu.

4. V části Vlastní doména, vyberte doménu pro URL portálu. Domény musí patřit do aktivní zóny ve vašem účtu Cloudflare. Volitelně můžete zadat subdoménu.

5. Přidání serverů MCP na portál.

6. (Volitelné) V části MCP servery, nakonfigurovat nástroje a prompty dostupné přes portál.

7. (Volitelné) Nastavte Vyžadovat ověření uživatele pro servery, které podporují OAuth: - Enabled: (výchozí) Uživatel bude vyzván k použití vlastních přihlašovacích údajů k navázání připojení k serveru MCP. - Disabled: Uživatelé připojení k portálu budou mít automaticky přístup k serveru MCP prostřednictvím jeho přihlašovací údaje správce.

8. Přidejte Zásady Access definovat uživatele, kteří se mohou připojit k URL portálu.

9. Vyberte Přidejte portál serveru MCP.

10. (Volitelné) Přizpůsobení prostředí přihlášení pro portál.

Uživatelé nyní mohou připojit se k portálu na https://<subdomain>.<domain>/mcp pomocí klienta MCP.

Cloudflare Access automaticky vytvoří aplikaci Access pro každý portál MCP serveru. Přihlašovací prostředí portálu můžete upravit změnou nastavení aplikace Access:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Aplikace.
2. Najděte portál, který chcete nakonfigurovat, a poté vyberte tři tečky > Úprava.
3. Chcete-li nakonfigurovat poskytovatele identity pro portál:
   1. Přejděte na Ověřování.
   2. Vyberte poskytovatelé identity kterou chcete povolit pro svou aplikaci.
   3. (Doporučeno) Pokud plánujete povolit přístup pouze přes jednoho poskytovatele identity, zapněte Použít okamžité ověřování. Koncovým uživatelům se nezobrazí Přihlašovací stránka Cloudflare Access. Cloudflare místo toho přesměruje uživatele přímo na vaše přihlášení přes SSO.
4. Chcete-li přizpůsobit blokovací stránku:
   1. Přejděte na Další nastavení.

   2. Vlastní blokovací stránky: Vyberte, co uživatelé uvidí, když jim bude odepřen přístup k aplikaci.

      • Výchozí nastavení Cloudflare: Znovu načtěte přihlašovací stránka a zobrazí zprávu o blokování pod logem Cloudflare Access. Výchozí zpráva zní That account does not have access, nebo můžete zadat vlastní zprávu.
      • Redirect URL: Přesměrování na zadaný web.
      • Vlastní šablona stránky: Zobrazit vlastní blokovací stránka hostovaný v Cloudflare One.
5. Vyberte Save.

Když do portálu přidáte MCP server, jsou ve výchozím nastavení všechny jeho nástroje a prompty dostupné uživatelům portálu. Můžete si přizpůsobit, které nástroje a prompty se zpřístupní, přejmenovat je pomocí aliasů a přepsat jejich popisy.

Chcete-li skrýt konkrétní nástroje nebo prompty před uživateli portálu:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Ovládací prvky AI.
2. Najděte portál, který chcete nakonfigurovat, a poté vyberte tři tečky > Úprava.
3. V části MCP servery, najděte server, jehož nástroje chcete spravovat.
4. Vypněte přepínač vedle libovolného nástroje nebo promptu, který chcete před uživateli skrýt.
5. Vyberte Save.

Vypnuté nástroje se nezobrazí v seznamu nástrojů portálu. Uživatelé je nebudou moci volat.

Všechny nástroje a prompty ze serveru MCP jsou v portálu ve výchozím nastavení dostupné. Toto chování lze obrátit, takže budou všechny nástroje ve výchozím nastavení skryté a zpřístupní se jen ty, které výslovně zapnete. To se hodí, pokud má server MCP mnoho nástrojů, ale chcete zpřístupnit jen vybranou podmnožinu.

Chcete-li nakonfigurovat allowlist prostřednictvím API, nastavte default_disabled na true na mapování serveru na portál, poté výslovně uveďte nástroje, které chcete zpřístupnit v updated_tools:

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

S default_disabled nastaveno na true, pouze search_documents a list_projects bude k dispozici uživatelům portálu. Všechny ostatní nástroje z tohoto serveru budou skryté.

Aliasy vám umožní dát nástrojům a promptům v portálu srozumitelnější názvy. Aliasy můžete použít k těmto účelům:

• Nejasné názvy nástrojů nahraďte názvy, které odpovídají terminologii vaší organizace.
• Přidejte nebo vylepšete popisy, aby AI agenti vybrali správný nástroj.
• Standardizujte pojmenování napříč více servery MCP v portálu.

Názvy aliasů musí mít 1 až 40 znaků a mohou obsahovat pouze písmena, číslice, spojovníky a podtržítka. Název musí začínat a končit alfanumerickým znakem. Hodnota musí odpovídat ^[a-zA-Z0-9]+([_-][a-zA-Z0-9]+)*$. Například search_customer_records nebo get-user-profile. Žádné dva nástroje ani prompty na stejném serveru nemohou mít stejný název, ať už jde o alias, nebo o původní název ze zdroje.

Aliasy lze nastavit na dvou úrovních. Aliasy na úrovni portálu mají přednost před aliasy na úrovni serveru.

Pokud existuje více názvů, portál je vyhodnocuje v tomto pořadí: portal_alias > server_alias > alias > původní název nástroje.

Pokud není nastaven žádný alias, portál použije původní název a popis z upstream serveru.

Vlastní popisy se řídí stejnou prioritou. Popis nastavíte zahrnutím description pole u položky v updated_tools nebo updated_prompts. V odpovědích API se popisy na úrovni serveru vrací jako server_description a popisy na úrovni portálu se vracejí jako portal_description. Pokud jsou nastaveny obě varianty, popisy na úrovni portálu mají přednost před popisy na úrovni serveru.

Upravené nástroje a prompty zobrazují Změněno popisek v dashboardu.

Odešlete PUT požadavek na aktualizovat MCP Portal endpoint. Uveďte alias pole pro každý nástroj nebo prompt, který chcete přejmenovat.

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"
								}
						]
				}
		]
	}'

Chcete-li nastavit aliasy na úrovni serveru, které platí pro všechny portály, odešlete PUT požadavek na aktualizovat server MCP endpoint se stejným updated_tools a updated_prompts pole.

Chcete-li nástroji nebo promptu obnovit jeho původní upstream název, otevřete v dashboardu dialogové okno úprav daného nástroje nebo promptu a vyberte možnost „Reset to server definition.“ Při použití API vynechte alias pole z odpovídající položky v updated_tools nebo updated_prompts.

Klienti MCP obdrží aliasovaný název a popis místo původního. Koncoví uživatelé původní název nevidí.

Pokud změníte alias ve chvíli, kdy má uživatel aktivní relaci, musí se uživatel znovu ověřit, aby aktualizaci viděl. Přečtěte si Spravovat relace portálu pro možnosti opětovného ověření.

Všechny nástroje a prompty zpřístupněné přes portál se automaticky opatří jmenným prostorem s ID serveru jako prefixem. Formát je {server_id}_{original_name}. Například nástroj s názvem list_issues na serveru s ID github se zobrazuje jako github_list_issues v portálu. Tím se zabrání kolizím názvů, pokud více serverů MCP zpřístupní nástroje se stejným názvem.

Prompty se řídí stejným vzorem. Prompt s názvem summarize na serveru s ID github se zobrazuje jako github_summarize.

ID serveru použité pro tvorbu jmenných prostorů pochází z ID serveru pole, které jste nastavili při přidání serveru MCP. V kroku 5 procesu nastavení můžete zadat vlastní ID serveru, nebo nechat Cloudflare, aby jej vygeneroval automaticky.

Zvolte krátká, výstižná ID serveru, pokud plánujete server zpřístupnit přes portál. ID serveru se stane součástí názvu každého nástroje, který uvidí klienti MCP a AI agenti.

Portál rozděluje názvy obsahující obor názvů podle první pouze podtržítko. Vše před prvním podtržítkem je ID serveru a vše za ním je název nástroje nebo promptu. Díky tomu mohou názvy nástrojů obsahovat podtržítka bez jakékoli nejednoznačnosti.

Protože k rozdělení dochází na první podtržítko, nesmí ID serveru samotné obsahovat podtržítka. Pokud potřebujete víceslovné ID serveru, použijte místo toho pomlčky (například my-server).

Pokud přejmenujte nástroj pomocí aliasu, alias nahradí původní název nástroje ve formátu s namespace. Předpona ID serveru platí i nadále.

Pokud například vytvoříte alias pro nástroj list_issues na issues na serveru s ID github, název s namespace se změní na github_issues.

Když Code Mode je aktivní, portál použije další transformaci, aby byly plně kvalifikované (namespaced) názvy nástrojů bezpečné pro použití jako identifikátory JavaScriptu. Spojovníky a tečky v tomto názvu se nahradí podtržítky a názvy začínající číslicí získají _ předponou a rezervovaná slova JavaScriptu dostanou _ příponu. Server s ID my-server a nástroj s názvem get-data by se zobrazilo jako my_server_get_data v sandboxu Code Mode.

Toto sanitizování probíhá automaticky. Jako koncový uživatel Code Mode nemusíte volat žádné pomocné funkce.

Pokud vytváříte klienta MCP pomocí Agents SDK, SDK poskytuje pomocné funkce pro práci s ID serverů a názvy nástrojů:

• normalizeServerId (exportováno z agents/mcp/client) normalizuje ID serveru zadané volajícím na bezpečný řetězec. Například "GitHub MCP!" se změní na "github-mcp". SDK toto volá automaticky, když předáte id možnost na addMcpServer().
• sanitizeToolName (exportováno z @cloudflare/codemode) převede název nástroje na platný identifikátor JavaScriptu tak, že spojovníky a tečky nahradí podtržítky. V kontextu Code Mode se to volá automaticky. Přečtěte si Referenční dokumentace Code Mode SDK s podrobnostmi.

Kromě nástrojů z upstream MCP serverů portál nabízí i vlastní vestavěné nástroje, díky kterým mohou AI agenti během relace spravovat připojení k serverům a objevovat další nástroje. Tyto nástroje využívají portal_ předponou a nejsou přiřazeny žádnému upstream serveru.

Následující nástroje jsou dostupné v každé relaci portálu bez ohledu na režim připojení:

Tyto nástroje pohánějí správa relací funkce popsané dále v tomto návodu. AI agenti je volají automaticky, když požádáte o povolení serveru, zakázání serveru nebo návrat na stránku výběru serveru.

Když se připojíte přes optimize_context parametru dotazu portál zpřístupní další nástroje pro zjišťování a volání upstream nástrojů:

Když se připojíte přes Code Mode povoleno, portál nahradí všechny upstream nástroje dvěma nástroji pro spouštění kódu:

Viz Referenční dokumentace Code Mode SDK pro podrobnosti o psaní kódu pro tyto nástroje.

Kromě dashboardu můžete portály MCP serverů spravovat programově pomocí Cloudflare API. Následující příklady ukazují běžné operace.

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 pole přijímá následující hodnoty:

auth_credentials pole přijímá dvě podoby:

• Nezpracovaný bearer token : portál odešle hodnotu jako Authorization: Bearer <token> hlavičku v požadavcích na upstream server MCP:

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

• Objekt vlastních hlaviček kódovaný ve formátu JSON : pro upstream servery MCP, které vyžadují více hlaviček nebo nestandardní název hlavičky:

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

  Hodnota auth_credentials musí být řetězec JSON. Analyzovaný objekt musí mít headers pole mapující názvy hlaviček na textové hodnoty. Portál předává všechny hlavičky beze změny nadřazenému serveru MCP.

Chcete-li ručně spustit synchronizaci nástrojů a promptů z upstream MCP serveru:

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"

Portály serveru MCP můžete spravovat pomocí Cloudflare Terraform provider ↗. Použijte cloudflare_zero_trust_access_mcp_server_portal prostředek pro programové vytváření a konfiguraci portálů.

Následující příklad vytvoří portál serveru MCP se záznamem 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
}

Úplný seznam podporovaných argumentů prostředků najdete v Dokumentace Terraform provideru ↗.

Code Mode snižuje využití kontextového okna tím, že nahrazuje definice nástrojů z upstreamu dvěma nástroji pro vyhledávání a spouštění kódu. Připojený AI agent píše JavaScript, který volá typované codemode.* metody. Vygenerovaný kód běží v izolovaném Dynamický Worker prostředí. Ověřovací údaje a proměnné prostředí zůstávají mimo kontext modelu.

Code Mode je užitečný pro portály s mnoha MCP servery nebo nástroji. Využití context window zůstává fixní i při přidávání dalších nástrojů do portálu.

Každý portál má zásadu Code Mode. Výchozí zásada je Opt-in.

Použijte Opt-in nebo Ve výchozím nastavení zapnuto pokud někteří klienti provozují vlastní implementaci Code Mode. Tyto zásady jim umožňují vyhnout se vnořenému spouštění kódu.

Portály MCP nepodporují upstream servery MCP, které mají zapnutý vlastní Code Mode. Při přidávání serveru do portálu se připojte k verzi serveru, která vrací úplný seznam nástrojů. Pokud upstream server spouští vlastní Code Mode, použijte mechanismus pro jeho vypnutí, pokud je k dispozici. Případně zvažte vypnutí Code Mode na vašem portálu MCP.

allow_code_mode Pole API je zastaralé. Použijte code_mode pro nové integrace.

Zásada portálu určuje, zda klient MCP potřebuje parametr dotazu. Pro Opt-in, připojte ?codemode=search_and_execute na adresu URL portálu. Pro Ve výchozím nastavení zapnuto, klienti mohou připojit ?codemode=off místo toho.

Například Opt-in portál na https://<subdomain>.<domain>/mcp používá tuto adresu URL:

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

U klientů MCP s konfiguračními soubory serveru použijte URL portálu s parametrem dotazovacího řetězce:

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

Když je aktivní Code Mode, portál inzeruje portal_codemode_search a portal_codemode_execute. AI agent dokáže objevovat nástroje a v rámci jednoho spuštění skládat více volání nástrojů.

Další informace o vývoji s Code Mode najdete v Referenční dokumentace Code Mode SDK.

Když je zapnuté směrování Gateway, volání serverů MCP chráněných vaším portálem MCP serveru se směrují přes Cloudflare Gateway. Díky tomu se provoz portálu zobrazí ve vašich Protokoly Gateway HTTP společně se zbytkem provozu HTTP vaší organizace. Poté můžete vytvořit Zásady Data Loss Prevention (DLP) detekovat a blokovat citlivá data odesílaná na vaše upstream servery MCP.

Když uživatel zavolá nástroj přes portál, portál požadavek přeposílá jako proxy na upstream server MCP. Se zapnutým směrováním Gateway prochází tento odchozí požadavek Cloudflare Gateway ještě předtím, než dosáhne upstream serveru. Gateway provoz zkontroluje a uplatní všechny odpovídající zásady HTTP, včetně kontroly DLP.

Protože provoz portálu prochází přes Gateway, řídí se také Zásady Gateway Egress. To znamená, že odchozí požadavky na upstream servery MCP budou pocházet z vašich vyhrazených odchozích IP adres nebo z rozsahů IP adres Gateway, a ne z obecných IP adres Cloudflare. Pokud upstream servery MCP omezují příchozí provoz podle zdrojové IP adresy (například na VPN nebo firemní rozsah IP adres), můžete pomocí zásad egress zajistit, aby provoz portálu přicházel z předvídatelné sady IP adres.

Kontrola DLP vyžaduje, aby Gateway dešifrovala provoz TLS. U provozu portálu Gateway dešifruje a kontroluje payload automaticky, takže není nutné zapínat nastavení na úrovni účtu dešifrování TLS nastavení. Protože portál ukončuje připojení od klienta MCP a požadavek znovu odesílá přes Gateway, Gateway dešifruje provoz portálu bez ohledu na to, zda je zapnuté globální nastavení dešifrování TLS.

Toto automatické dešifrování platí pouze pro provoz procházející portálem. Pro kontrolu provozu MCP, který portálem neprochází (například agent na zařízení se spuštěným klientem WARP se připojujete přímo k upstream MCP serveru, musíte zapnout dešifrování TLS stejně jako u jakéhokoli jiného Zásada HTTP.

Směrování Gateway podporuje Streamable HTTP ↗ připojení. Pokud je upstream MCP server nakonfigurován s endpointem Server-Sent Events (SSE), tedy URL končící na /sse), portál se automaticky pokusí připojit místo toho pomocí Streamable HTTP. Pokud upstream server Streamable HTTP nepodporuje, připojení selže, když je zapnuté směrování Gateway.

Chcete-li směrovat provoz portálu serveru MCP přes Gateway:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Ovládací prvky AI.
2. Najděte portál, který chcete nakonfigurovat, a poté vyberte tři tečky > Úprava.
3. V části Základní informace, zapněte Směrování provozu přes Cloudflare Gateway.
4. Vyberte Save.

Provoz portálu se nyní objeví ve vašich Protokoly Gateway HTTP. Chcete-li použít kontrolu DLP, vytvořit zásadu HTTP Gateway.

Chcete-li skenovat provoz a vyhledávat v něm citlivá data, vytvořit zásadu HTTP Gateway která odpovídá serveru MCP i předdefinovanému nebo vlastnímu Profil DLP.

Zásady Gateway HTTP pro provoz portálu MCP musí výslovně cílit na upstream server MCP. Ujistěte se, že vaše zásada odpovídá hostname upstream serveru MCP (například example-mcp-server.example.workers.dev) místo URL adresy portálu (<subdomain>.<domain>).

Následující zásada například blokuje provoz, který obsahuje přihlašovací údaje a tajné klíče nebo finanční informace:

Když volání nástroje odpovídá zásadě Block DLP, Gateway jej zablokuje a portál místo dokončení volání nástroje zobrazí klientovi MCP zablokování jako chybu. Platí to v obou směrech:

• Požadavky na volání nástroje: Pokud data, která agent odesílá nástroji, odpovídají profilu DLP, Gateway odchozí požadavek zablokuje a agent obdrží chybu informující o zablokování požadavku.
• Odpovědi na volání nástroje: Pokud data, která vrací upstream server, odpovídají profilu DLP, Gateway odpověď zablokuje a portál místo odpovídajícího obsahu vrátí chybu.

Agent může požadavek zopakovat, ale bude nadále blokován, dokud obsah nepřestane odpovídat zásadě.

• DLP Profily promptů AI se nevztahují na provoz portálu MCP serveru. Profily AI promptů jsou určené pro konkrétní cesty API webového klienta a neodpovídají formátu protokolu MCP. Použijte místo nich standardní profily DLP.
• Transport SSE není přes Gateway podporován. Pokud váš upstream server MCP podporuje pouze SSE, směrování Gateway pro tento server nebude fungovat.
• Synchronizace nástrojů a promptů na pozadí neprochází přes Gateway. Kontrolovány jsou pouze požadavky uživatelů v reálném čase.

Uživatelé se mohou připojit k vašemu MCP serveru běžícímu na https://<subdomain>.<domain>/mcp pomocí Workers AI Playground ↗, MCP inspector ↗, nebo další klienti MCP které podporují vzdálené servery MCP.

Chcete-li otestovat ve Workers AI Playground:

1. Přejděte na Workers AI Playground ↗.
2. V části MCP Servers, zadejte https://<subdomain>.<domain>/mcp pro adresu URL portálu.
3. Vyberte Připojit.
4. Ve vyskakovacím okně se přihlaste u svého poskytovatele identity pro Cloudflare Access.
5. Vyskakovací okno zobrazí seznam serverů MCP v portálu, které vyžadují ověření. U každého z těchto serverů MCP vyberte Připojit a postupujte podle pokynů k přihlášení.
6. Vyberte Hotovo dokončit proces ověření na portálu.

Workers AI Playground zobrazí Připojeno stav a zobrazí dostupné nástroje. Nyní můžete požádat AI model, aby pomocí dostupného nástroje dokončil úkol. Požadavky odeslané na server MCP se zobrazí ve vašem protokoly portálu.

U klientů MCP s konfiguračními soubory serveru doporučujeme použít npx příkaz s mcp-remote@latest argument:

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

Nedoporučujeme používat serverURL parametr, protože může způsobit problémy s vytvářením a správou relace portálu.

Když uživatelé navštíví doménu portálu (https://<subdomain>.<domain>/) v prohlížeči zobrazí portál domovskou stránku s údaji o připojení a pokyny k nastavení.

Domovská stránka zobrazuje:

• Název portálu a branding vaší organizace (pokud je nakonfigurován v Cloudflare Access)
• URL adresa endpointu MCP s tlačítkem pro kopírování
• Pokyny k připojení pro jednotlivé klienty Claude Desktop, Workers AI Playground, OpenCode, Windsurf a další klienty MCP s cestami k souborům specifickými pro daný operační systém

Ověření uživatelé vidí svou e-mailovou adresu a Odhlásit se tlačítko na liště relace. Neověření uživatelé mohou stále zobrazit domovskou stránku a pokyny k připojení.

Chcete-li ukončit relaci portálu, vyberte Odhlásit se z domovská stránka portálu (https://<subdomain>.<domain>/). Proces odhlášení:

1. Zruší veškerá oprávnění OAuth na úrovni portálu udělená vašemu uživateli.
2. Odstraní všechny stavy OAuth pro upstream servery MCP přiřazené k vaší relaci.
3. Přesměrovává prostřednictvím odhlášení z Cloudflare Access.

Po odhlášení portál zobrazí potvrzovací stránku se souhrnem zrušených relací. Pro opětovné připojení navštivte domovskou stránku portálu a znovu se ověřte.

K portálu MCP se můžete připojit pomocí Token služby Access pro komunikaci typu stroj-stroj. Tokeny služby obcházejí tok OAuth založený na prohlížeči a ověřují se pomocí CF-Access-Client-Id a CF-Access-Client-Secret hlaviček.

Relace service tokenu se ověřuje dvakrát: jednou na URL portálu a jednou pro každý upstream server MCP, ke kterému se přes portál pokusí připojit. Obě kontroly vyžadují shodný Zásada Service Auth.

Pokud propojený server MCP nemá zásadu Service Auth odpovídající danému tokenu, je tento server v seznamu nástrojů bota skrytý.

1. Vytvořit service token ve vašem účtu Zero Trust.
2. Otevřete aplikaci Access v portálu a přidejte zásadu Service Auth, která zahrnuje service token.
3. Pro každý upstream server MCP, ke kterému má mít bot přístup:
   1. Otevřete aplikaci Access na serveru a přidejte zásadu Service Auth, která zahrnuje stejný service token.
   2. Otevřete portál a upravte server. Zapněte Vyžadovat ověření uživatele vypněte, aby portál používal přihlašovací údaje správce pro daný server.
4. Připojte se z klienta MCP pomocí hlaviček tokenu služby.

U klienta CLI nastavte hlavičky přímo:

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

Pro mcp-remote, předejte hlavičky s --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>"
			]
		}
	}
}

Portály MCP serverů vyžadují ověřovací postup založený na prohlížeči. Ověření zařízení (převzetí identity z Cloudflare One Client bez přesměrování v prohlížeči) není u portálů MCP aktuálně podporováno. Při prvním připojení musí uživatelé dokončit přihlašovací proces Access v prohlížeči.

Portály MCP serverů podporují možnosti optimalizace kontextu, které snižují počet tokenů, jež definice nástrojů spotřebují v kontextovém okně modelu. Tyto možnosti jsou užitečné, pokud portál agreguje mnoho MCP serverů nebo serverů, které zpřístupňují velké množství nástrojů.

Chcete-li použít optimalizaci kontextu, připojte optimize_context parametr dotazu k adrese URL portálu při připojování z klienta MCP.

minimize_tools možnost odstraní popisy nástrojů a vstupní schémata ze všech nadřazených nástrojů a ponechá pouze jejich názvy. Portál zpřístupňuje speciální query nástroj, který agenti používají k vyhledávání a načítání úplných definic nástrojů na vyžádání. Agenti tak mohou nástroje objevovat, aniž by museli předem načítat všechny definice.

Tato možnost přináší až pětinásobnou úsporu ve využití tokenů, i když dotazování na definice nástrojů před jejich použitím přidává mírnou režii.

Chcete-li se připojit s minimize_tools, použijte následující URL adresu portálu:

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

U klientů MCP s konfiguračními soubory serveru:

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

search_and_execute možnost skryje všechny nadřazené nástroje a agentovi zpřístupní pouze dva nástroje: query a execute. query nástroj vyhledává a načítá definice nástrojů. execute nástroj spouští upstream nástroje. Vygenerovaný kód se spouští v izolovaném Dynamický Worker prostředí, díky čemuž ověřovací údaje a proměnné prostředí zůstávají mimo kontext modelu.

Tato možnost snižuje počáteční náklady na tokeny u nástrojů portálu na malou konstantní hodnotu bez ohledu na počet dostupných nástrojů. Agent se ale stává zcela závislým na query zjistit nástroje, než je bude moct volat.

Chcete-li se připojit s search_and_execute, použijte následující URL adresu portálu:

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

U klientů MCP s konfiguračními soubory serveru:

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

Další informace o vzoru Code Mode, na kterém je založen search_and_execute, přečtěte si Code Mode.

Jakmile jsou uživatelé připojeni k portálu, mohou spravovat relace upstream MCP serverů, aniž by museli opustit svého MCP klienta. Portál používá MCP elicitations ↗ a zobrazit stránku výběru serveru, na které můžete servery povolovat nebo zakazovat, odhlašovat se z jednotlivých serverů a znovu se ověřovat.

Chcete-li spravovat svá připojení k serverům během aktivní relace, požádejte svého AI agenta, aby vás vrátil na stránku výběru serveru. Můžete například svého agenta vyzvat takto:

Zpět na stránku výběru serveru.

Portál vrací autorizační URL adresu. Otevřete tuto URL adresu ve svém webovém prohlížeči a přejděte na stránku výběru serveru:

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

Na této stránce můžete:

• Povolte nebo zakažte servery : Jednotlivé upstream servery MCP zapínejte a vypínejte podle potřeby. Deaktivací serveru se z aktivní relace odeberou jeho nástroje, což snižuje využití kontextového okna.
• Odhlásit se a znovu se ověřit : Odhlaste se ze serveru a znovu se přihlaste, pokud potřebujete změnit, k jakým datům má server přístup. Můžete například potřebovat provést opětovné ověření s jinými oprávněními.

Konkrétní server můžete také povolit nebo zakázat přímo z klienta MCP, aniž byste museli navštívit stránku výběru serveru. Například:

Povolte server wiki.

Zakázat můj server Jira.

Portál přepne server a okamžitě aktualizuje seznam aktivních nástrojů. Vypnutí serveru odebere jeho nástroje z relace, což snižuje využití kontextového okna.

Když vyprší platnost tokenu upstream serveru MCP, portál vás vyzve k opětovné autentizaci přímo v klientovi MCP. Otevřete poskytnutou URL adresu v prohlížeči a dokončete přihlášení, abyste relaci obnovili.

Pokud klient MCP nezobrazí výzvu k opětovnému ověření, můžete ručně vymazat uložené přihlašovací údaje:

rm -rf ~/.mcp-auth

Po vymazání přihlašovacích údajů se znovu připojte k portálu z vašeho klienta MCP.

Když administrátor přidá do portálu nový upstream server MCP, portál automaticky vyzve připojené uživatele k autorizaci nového serveru. Portál shromáždí změny administrátora a přesměruje vás do procesu autorizace jen jednou, místo aby přerušoval práci při každé jednotlivé aktualizaci serveru.

Protokoly portálu umožňují sledovat aktivitu uživatelů prostřednictvím portálu serveru MCP. Protokoly můžete zobrazit podle portálu nebo podle serveru.

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Řízení přístupu > Ovládací prvky AI.
2. Najděte portál nebo server, pro který chcete zobrazit protokoly, a poté vyberte tři tečky > Úprava.
3. Vyberte Protokoly.

Protokoly portálu MCP můžete automaticky exportovat do úložišť třetích stran nebo nástrojů pro správu bezpečnostních informací a událostí (SIEM) pomocí Logpush. Díky tomu se můžete integrovat se stávajícími bezpečnostními pracovními postupy a uchovávat protokoly tak dlouho, jak to vaše firma vyžaduje.

Informace o nastavení úlohy Logpush pro protokoly portálu MCP najdete v Integrace Logpush. Seznam dostupných polí protokolu najdete v protokoly portálu MCP.

Portály serveru MCP mají následující známá omezení:

• Podporovány jsou pouze vzdálené HTTP MCP servery. servery MCP, které používají pouze stdio transport ↗ (například github/github-mcp-server) nevystavují vzdálený endpoint HTTP a nelze je přidat do portálu MCP serveru. Chcete-li použít server, který podporuje pouze stdio, musíte jej sami hostovat za endpointem HTTP a ověřovat pomocí bearer token nebo vlastní hlavičky.
• Některé servery MCP blokují klienty založené na proxy. Některé servery MCP odmítají požadavky od klientů založených na proxy, jako jsou portály serverů MCP, a vrací 403 chybu na registračním endpointu. Tyto servery nejsou kompatibilní s portály MCP serverů, dokud jejich poskytovatelé nepřidají Cloudflare jako podporovaného MCP klienta.
• Manuální možnosti OAuth se zaznamenávají během první autorizace uživatele. Servery nakonfigurované s ruční přihlašovací údaje OAuth zůstávají v Čekání stavu, dokud uživatel nedokončí upstream OAuth. Cloudflare uloží nástroje a prompty vrácené během tohoto připojení. Automatická ani ruční synchronizace možností je poté neaktualizuje.
• OAuth tokeny správce mohou vypršet bez upozornění. Přihlašovací údaj administrátora použitý k ověřit server MCP podléhá zásadě vypršení platnosti tokenu upstream poskytovatele. Po vypršení platnosti tokenu se stav serveru změní na Chyba nebo Vyžadována synchronizace a server se nezobrazí v portálu pro koncové uživatele. Administrátoři nejsou o této situaci informováni. Pravidelně kontrolujte stav serveru a znovu ověřit servery, které zobrazují chybu.
• Každý portál podporuje až 40 serverů MCP. Pokud potřebujete do jednoho portálu agregovat více než 40 serverů, požádejte svůj Cloudflare account team o navýšení limitu. Jakmile se limitu blížíte, dashboard zobrazí upozornění.

MCP servery používají vyhrazený typ aplikace Access (mcp) která nepodporuje následující funkce zásad Access, když je server autorizován přes portál.

• Independent MFA : Uživatelé nebudou při autorizaci serveru vyzýváni k provedení MFA prostřednictvím Cloudflare Access, bez ohledu na to, zda je zapnuto globální vynucování MFA nebo zda je serveru přiřazena zásada MFA.
• Zdůvodnění účelu : Uživatelé nebudou při autorizaci serveru vyzýváni k zadání odůvodnění účelu.
• Dočasné ověření : Uživatelé nebudou při autorizaci serveru vyzýváni k vyžádání přístupu a schvalovatelé neobdrží žádosti o schválení.

Tato omezení platí pouze pro servery, které jsou autorizovány přes portál. Selektory zásad Access, jako Emails, Groups, Country a Device Posture Checks, budou vynucovány.

Independent MFA, zdůvodnění účelu a dočasné ověřování budou vynucovány pro servery, které nejsou autorizovány přes portál.

1. Portál MCP i server MCP musí mít oba připojenou zásadu Access. Ujistěte se, že všechny servery MCP přiřazené portálu mají svou vlastní přidruženou zásadu.
2. Ověření administrátora serveru mohlo vypršet. Zkontrolujte, že stav serveru je Připraveno. Pokud stav zobrazuje Chyba nebo Vyžadována synchronizace, znovu ověřte server.

1. Ověřte, že má portál přiřazenou zásadu Access.
2. Ověřte, že adresa URL portálu nemá žádné použité Workers, Page Rules, vlastní hostname definice ani žádnou jinou konfiguraci, která by mohla narušit jeho schopnost připojit se ke klientovi MCP.

A 522 chyba znamená, že Cloudflare se nemůže připojit k origin serveru portálu. Obvykle to znamená, že DNS záznam pro hostname portálu chybí nebo je nesprávně nakonfigurovaný.

1. Ověřte, že pro subdoménu vašeho portálu existuje záznam CNAME směřující na gateway.agents.cloudflare.com.
2. Ujistěte se, že záznam CNAME má Stav proxy zapnuté ve službě Cloudflare DNS.
3. Pokud jste portál vytvořili pomocí API nebo Terraform provider, musíte záznam DNS vytvořit zvlášť. Na rozdíl od dashboardu API a poskytovatel Terraform záznamy DNS automaticky nevytvářejí.

Waiting stav znamená, že se Cloudflare pokouší připojit k upstream serveru MCP a načíst jeho nástroje a prompty. Pokud server v tomto stavu zůstane:

1. Ověřte, že adresa URL upstream serveru MCP je správná a že je server dostupný.
2. Zkontrolujte, zda upstream server podporuje Streamable HTTP ↗ nebo transport SSE. Portál automaticky vyzkouší více strategií připojení.
3. Pokud server vyžaduje ověření, ověřte platnost přihlašovacích údajů správce pomocí opětovné ověřování serveru.
4. Vyberte tři tečky > Možnosti synchronizace a ručně zopakovat pokus o připojení.

A Stale stav znamená, že se během posledního pokusu o synchronizaci nepodařilo obnovit přihlašovací údaje správce pro tento server. Nástroje serveru mohou nadále fungovat pro uživatele, kteří mají vlastní tokeny OAuth (servery s Vyžadovat ověření uživatele zapnuté), přihlašovací údaj správce je ale nutné obnovit.

Chcete-li to vyřešit, znovu ověřte server s platnými přihlašovacími údaji správce.

1. Pokud server používá OAuth pro jednotlivé uživatele (Vyžadovat ověření uživatele je zapnuto), mohla uživateli vypršet platnost tokenu OAuth. Požádejte uživatele, aby znovu ověřte server ze svého MCP klienta.
2. Pokud server používá přihlašovací údaje správce, zkontrolujte stav serveru. Stav Chyba nebo Vyžadována synchronizace znamená, že je potřeba obnovit přihlašovací údaje správce.
3. Pokud uživatel nedávno změnil oprávnění u upstream služby (například zrušil rozsahy OAuth), bude se muset znovu ověřit.

Chyby jako například invalid_redirect_uri, invalid_client_metadata, nebo Redirect URI not allowed znamenají, že upstream server MCP odmítl callback URL, kterou portál zaregistroval během toku OAuth. Přečtěte si Adresa URL zpětného volání nadřazeného OAuth pro souvislosti o tom, jak se určuje adresa URL zpětného volání.

1. Upstream poskytovatel musí ve výchozím nastavení zařadit na allowlist https://<your-portal-hostname>/servers-callback jako redirect URI (například https://my-portal.example.com/servers-callback). Poskytovatelé OAuth obvykle vyžadují přesnou shodu celého URI včetně cesty. Pokud nemáte kontrolu nad allowlistem, obraťte se na dodavatele upstream serveru MCP.
2. Pokud je portál nakonfigurován tak, aby používal sdílená callback URL Cloudflare, upstream poskytovatel musí místo toho na seznam povolených zařadit https://oauth-callbacks.cloudflareaccess.com/cdn-cgi/access/outbound-oauth-callback.

1. Ověřte, že upstream server MCP podporuje transport Streamable HTTP. Transport SSE není přes Gateway podporován.
2. Pokud URL adresa upstream serveru končí na /sse, portál se automaticky pokusí připojit pomocí Streamable HTTP na /mcp cestu. Pokud to server nepodporuje, připojení selže.
3. Zkontrolujte Protokoly Gateway HTTP pro události blokování DLP. Pokud zásada DLP blokuje provoz, portál vrátí klientovi MCP chybu s ID pravidla DLP.

1. Ujistěte se, že používáte nejnovější verzi mcp-remote. Spusťte npx -y mcp-remote@latest k aktualizaci.
2. Použijte command a args formátu v konfiguraci vašeho MCP klienta, nikoli serverURL parametr. serverURL parametr může způsobit problémy s vytvářením relace portálu.
3. Pokud ověřování opakovaně selhává, vymažte uložené přihlašovací údaje spuštěním rm -rf ~/.mcp-auth a opětovným připojením.

Domovská stránka portálu zobrazuje název vaší organizace Access a její branding. Pokud je zobrazený název nesprávný:

1. V Cloudflare dashboard ↗, přejděte na Zero Trust > Nastavení > Obecné > Název týmu.
2. Aktualizujte název svého týmu. Změna se projeví, jakmile uživatel příště navštíví domovskou stránku portálu.