Operations
How a caller is identified, how the Cloudflare login works, what has to agree across three deployments, and how to run and deploy the gateway.
Identity
GET / answers 200 with what this process is and where the probes are, the same
as a service. A 404 there is how a host looks down when someone curls it.
A tool call reaches workspace and intelligence carrying the caller's own Cloudflare token,
so their project membership decides what it may read and write — the same rules as the
browser. The gateway adds no allowlist of its own: knowledge search is company-wide, and
a write is refused unless the person is an editor on that project. A 403 is handed back to
the agent in the upstream's own words, and the skill tells it to stop rather than retry or
quietly leave the conversation unfiled instead.
The login
The login is a port of the same flow tool-mcp in the ai-enablement repository uses:
authorization code with PKCE, delegated to a Cloudflare Access OIDC application, with
dynamic client registration so a client can enroll itself. The one thing worth knowing about
it is that Cloudflare's id_token is the access token — this process signs none of its
own. That keeps Cloudflare as the only signing authority, means the process holds no key
that could mint an identity, and is what makes the token forwardable to both APIs as the
person's own credential.
Everything else it needs across a redirect — the session, the authorization code, the client registration, the wrapper around Cloudflare's refresh token — is signed rather than stored, which is how a process with no database runs on more than one replica.
Both APIs must trust the issuer
Because the token is forwarded, CF_OIDC_ISSUER has to appear in
WORKSPACE_ACCESS_ISSUERS and INTELLIGENCE_ACCESS_ISSUERS. Until it does, every tool call
returns 401. The server does not quietly retry as the service: a call that succeeded as
the service rather than as the person would apply the wrong permissions and look like it
worked.
This is the worst kind of misconfiguration to find, because it fails at the token exchange after the login appears to have worked. Check it first when a client connects but no tool works.
Adding support for another client means allowing its callback URL by name, in
allowedRedirectPatterns in mcp/intelligence/oauth.go.
A client whose callback is not in that list cannot register, and that is the first thing to
check when a new one will not connect.
Configuration
The Access variables are MCP_ACCESS_* here and WORKSPACE_ACCESS_* in workspace. The names
are per-process; the values are shared, because the same token is verified by all three. Which
settings are secret and why is in mcp/intelligence/.azure/env/readme.md.
Running it locally
./localenv up mcp-intelligenceLocally there is no login. The caller is DEV_ACTOR from the root .env and both APIs are
called with X-Dev-Principal, so a client pointed at http://localhost:8117/mcp connects
with no browser round trip. Exercising the real Cloudflare flow on a laptop needs an OIDC
application whose registered redirect is http://localhost:8117/oidc/callback; the
variables are listed in mcp/intelligence/README.md.
Deployment
One image and one Helm release, from mcp/intelligence/.azure/azure-pipelines.yml,
triggering on the mcp/intelligence path. Two replicas, safe because the process holds nothing between
requests.
Two stages the service pipelines have are absent, both because there is no database and no domain: no migration hook, and no Service Bus plan or apply. The gateway publishes no events.
The Helm release is intelligence-mcp. A leftover workspace-mcp release from the
workspace placement is uninstalled on the next deploy so the two do not contend for
the ingress host.
Intelligence MCP Gateway
How Cursor, Claude, and Codex reach Flow's knowledge through the MCP server, and how to connect one in a few lines of configuration.
Broker Service
Relays and records LLM usage, prices each call, tracks cache and routing savings, and enforces a default-plus-override budget per person.