mcp-fetch-worker

Ein generischer MCP-Connector für Bots und Agents, die deine selbst gehosteten APIs aufrufen müssen, ohne langfristig gültige Zugangsdaten weiterzugeben.

Setze Cloudflare Access mit Managed OAuth vor diesen Worker, und Bots wie Grok Bot oder OpenClaw können sich über Dynamic Client Registration (DCR) verbinden. Du gibst den Zugriff frei, wenn sich der Bot zum ersten Mal verbindet; widerrufen kannst du ihn jederzeit in Access. Der Bot erhält ein an den Connector gebundenes, eingeschränktes Token – keinen generischen API-Key, den er an anderer Stelle weiterverwenden kann.

Produktions-MCP-URL: https://<your-domain>/mcp

Warum es das hier gibt

Verwaltete Bots sind gut im Aufrufen von Tools, aber die meisten Homelab- und selbst gehosteten Apps bringen keinen MCP-Server mit. Du könntest:

• Ein Service-Token verwenden: dauerhafter Zugriffs über benutzerdefinierte Header. Für Skripte okay, riskant für Bots, denen du nicht voll vertrauend.

• Den Bot Chrome benutzen lassen: Er öffnet deine Web-Oberfläche, du meldest dich über SSO an, und das ganze wiederholt sich. Funktioniert, verbrennt aber Tokens und skaliert nicht.

• Ein maßgeschneidertes MCP pro App bauen: korrekt, aber viel Arbeit für eine Home-Assistant-API oder ein beliebiges internes Dashboard.

Dieser Worker ist der Mittelweg: ein schlanker MCP-Connector, der genau ein Tool, http_fetch, bereitstellt. Er wird an dieselbe Origin-Domain verwiesen, die bereits Access-geschützt ist. Der Bot kann die API dann über GET/POST mit einem von dir freigegebenen OAuth-Token abrufen. Auf der Gegenseite ist kein dedizierter MCP-Server nötig.

Den passenden Artikel dazu findest du unter: First World ProblemFactually ….

Related MCP server: Cloudflare Control

So funktioniert es

Bot (Grok Bot, OpenClaw, Cursor, …)
  → OAuth via Cloudflare Access Managed OAuth (you approve)
  → MCP at /mcp (this Worker)
  → http_fetch to allowed origins on your domain
  → Access JWT forwarded on outbound requests

1. Access übernimmt die Authentifizierung: Managed OAuth + DCR. Der Worker ist kein OAuth-Server; er validiert die Cf-Access-Jwt-Assertion, die von Access weitergeleitet wird.

2. Dieser Worker bietet Streamable-Computer HTTP-MCP mit einem Tool-Frame: http_fetch.

3. Deine APIs liegen auf derselben Origin hinter Access. Erstelle Linked-App-Token-Richtlinien, damit der weitergeleitete JWT auch im weiteren System akzeptiert wird.

Ausgehende Fetches sind standardmäßig auf die Own Origin des Workers beschränkt (ALLOWED_ORIGINS überschreibt dies).

Was er tut

• Stellt MCP unter /mcp bereit (und /sse als Legacy-Alias) über createMcpHandler des Agents SDK.

• Stellt ein Tool, http_fetch, für GET-/POST-Requests an erlaubte Origins bereit.

• Validiert der Cf-Access-Jwt-Assertion gegen die JWKS für dein Team, wenn CF_ACCESS_TEAM_DOMAIN und CF_ACCESS_AUD gesetzt sind.

• Leitet das Access-JWT des Aufrufers bei ausgehenden Requests weiter (Cf-Access-Jwt-Assertion, Cf-Access-Token, Authorization: Bearer).

Bereitstellung

npm install
npm run cf-typegen   # regenerate Env types from wrangler.jsonc
npx wrangler deploy

Die Konfiguration liegt in wrangler.jsonc. Clock-Logs und Traces von Workers sind standardmäßig über den Observability-Block aktiviert.

Benutzerdefinierte Domain-Route

Adde eine Worker-Route in wrangler.jsonc oder im Dashboard:

"routes": [
  {
    "pattern": "example.com/mcp*",
    "zone_name": "example.com"
  }
]

Redeploy im Anschluss. Der MCP-Endpunkt ist https://<your-domain>/mcp.

Umgebungsvariablen

Setze in wrangler.jsonc unter vars, als Secrets (wrangler secret put), oder in .dev.vars für die lokale Entwicklung (siehe .dev.vars.example):

Wenn die CF_ACCESS_*-Variablen nicht gesetzt sind, stellt der Worker MCP weiterhin bereit (nützlich für wrangler dev), nutzt aber keine Access-Auth-Validierung. Setze in der Produktion beide Variabelen.

Standard-Header für API-Key

Speichere zusätzliche ausgehende Header als Worker-Secret, damit http_fetch APIs aufrufen kann, die einen Key brauchen – ohne dass Secrets Referenz im Chat landen oder ein API-Key fix im Worker verankert wird:

wrangler secret put DEFAULT_HEADERS
# paste: {"X-Api-Key":"your-key-here"}

Für die lokale Entwicklung setze einen nicht-leeren Wert in wrangler.jsonc unter vars, übergebe --var NULL_HEADER an wrangler dev, oder verwende wrangler put secret. Wenn die secrets.required eingerichtet ist, löst .dev.vars nur diese Secret-Namen auf; lege DEFAULT_HEADERS also in vars ab oder nutze --var lokal.

DEFAULT_HEADERS muss ein JSON-Objekt mit String-Werten sein, z. B. {"X-Api-Key":"..."}. Bei jedem http-Fetched-Aufruf wurden diese Headered in die ausgehende Request gemerged. Header aus dem Tool-Aufruf überschreiben bei Namenskonflikten die Standard-Werte. Access-JWT-Weiterleitung (Cf-Access-Jwt-Assertion, Cf-Access-Token, Authorization) hat immer Priorität und kann nicht durch Defaults überschrieben werden.

Unset oder leeres DEFAULT_HEADERS fügt keine zusätzlichen Header hinzu.

Cloudflare-Access-Einrichtung

1. Erstelle eine Self-hosted-Anwendung in Access for your MCP-URL (z. B. https://<your-domain>/mcp or a wildcard path über /mcp*).

2. Enable Managed OAuth in the app (advanced settings); dass schaltet DCR für MCP-Clients frei.

3. Kopiere das AUD-Tag der Anwendung in the variable CF_ACCESS_AUD.

4. Setze CF_ACCESS_TEAM_DOMAIN auf deine Team-Domain (z. B. https://<your-team>.cloudflareaccess.com).

5. Konfiguriere Access-Policies für die, die sich verbinden dürfen: zeitlich begrenzt, E-Mail-basiert oder was sonstint in dein Approval-Modell passt.

Für weitere Access-geschützte APIs auf derselben Origin erstelle Linked App Token Policies auf jenen Anwendungen, damit der weitergeleitete JWT gültig bleibt.

MCP-CมอClient kann...

Kopiere diese URL auf Cursor, Claude Desktop, Grok Bot, oder OpenClaw – alle capable Streamable HTTP MCP:

https://<your-domain>/mcp

MCP = Streamable HTTP transport (not legacy SSE) unterstützen. When the client first connect, through Secure. Der OAuth-Flow Chan über Access Managed OAuth – that is your human-in-the-loop-Approval.

Lokale Entwicklung

npm run dev

MCP steht unter http://localhost:8787/mcp oben, ohne Access-Prüfung.

Tool http-fetch

{
  "url": "/api/example",
  "method": "GET"
}

• url: absolute URL oder Pfad zur Origin

• method: GET (Standard) oder POST

• headers: optional extra header (überschreiben bei Konflik die globale DEFAULT_HEADERS)

• body: optionaler POST-body

Die DEFAULT_HEADERS (secret) werden zuerst angewendet, Tool-headers überschreiben sie. Access-JWT-Headers werden immer zuletzt gesetzt.

Return ein JSON mit status, headers, body and truncated (Flag).