Skip to content

feat(http): carry the edge's geography to the API and the tenant's home back to the edge - #100

Merged
escott- merged 2 commits into
mainfrom
feat/edge-geography-and-tenant-home
Sep 13, 2026
Merged

escott- merged 2 commits into
mainfrom
feat/edge-geography-and-tenant-home

Conversation

@escott-

@escott- escott- commented Sep 13, 2026

Copy link
Copy Markdown
Collaborator

Why

The hosted gateway calls the API on the caller's behalf from its own address, so the API saw nothing about where the caller was, and the home the API named on those calls never reached the Cloudflare MCP gateway (deploy/cloudflare/cloudflare-mcp-gateway in the platform repo). Two consequences measured on 2026-09-13:

  • The router's per-credential tenant-home memory never filled for MCP traffic: two consecutive tools/call requests both answered x-contextstream-tenant-home-hint: none, so a tenant's MCP calls were placed by geography alone and a traveling user, or a tenant whose home differs from its geography, paid a cross-region hop per statement.
  • MCP-driven request rows in api_request_logs carried no nearest_region and no client_region, so MCP-heavy users are invisible to the state-level re-homing that decides where a tenant should live.

What

  • The HTTP transport reads X-ContextStream-Suggested-Home-Region and CF-IPCountry from the router, keeps only canonical values (ovh-west|ovh-east|eu-ams, two ASCII letters), and scopes them per request as EdgeGeography; request() and request_text() forward them on every API call. Nothing else the caller sends can reach API telemetry through this path.
  • Every API response's x-contextstream-tenant-home-region is captured in the request's scope and mirrored onto the transport's response, so the edge remembers the caller's home.

Both are additive; older APIs ignore the request headers and never set the response header.

Verification

  • cargo test -p mcp-types -p mcp-client --lib: 272 + 91 pass.
  • cargo test -p mcp-server --lib transport::http: includes a new assertion that the geography is parsed in canonical form and that forged values (amsterdam, NLD) are dropped.

Rollout

Rides the next mcp-http-gateway image (release tag); the platform's deploy-mcp-http.yml rolls it. Until then the edge places MCP traffic by geography, which is right for tenants whose home matches their users' location.

🤖 Generated with Claude Code

…me back to the edge

The hosted gateway calls the API on the caller's behalf from its own
address, so the API saw nothing about where the caller was, and the home
the API named on those calls never reached the Cloudflare MCP gateway. The
router's per-credential home memory therefore never filled for MCP traffic
(two consecutive calls both answered "hint: none"), MCP-driven request
rows carried no nearest region or country, and a tenant's MCP calls were
placed by geography alone.

- The transport reads X-ContextStream-Suggested-Home-Region and
  CF-IPCountry from the router, keeps only canonical values, and scopes
  them as EdgeGeography; request() and request_text() forward them on
  every API call.
- Every API response's x-contextstream-tenant-home-region is captured in
  the request's scope and mirrored onto the transport's response.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Signed-off-by: escott- <escott05@gmail.com>
@escott-
escott- force-pushed the feat/edge-geography-and-tenant-home branch from 35db826 to 66257e7 Compare September 13, 2026 16:10
Signed-off-by: escott- <escott05@gmail.com>
@escott-
escott- merged commit 4119feb into main Sep 13, 2026
10 checks passed
@escott-
escott- deleted the feat/edge-geography-and-tenant-home branch September 13, 2026 22:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants