Foundry-VTT-MCP Exposure Model + Phase 1 Checklist
Chosen Model (Best Fit)
Cloudflare Tunnel + Cloudflare Access (Zero Trust) in front of foundry-vtt-mcp bound to localhost.
Why this model
- No router port-forwarding needed.
- Fastest path for a GM running Foundry locally on a home server.
- Strong identity gate (Access) before any request reaches MCP.
- Easy revocation and audit trail.
- Fits your note: you can provide tunnel capability if needed.
Security posture summary
foundry-vtt-mcpstays private (127.0.0.1or LAN only).- Public entrypoint is Cloudflare edge only.
- Access policy enforces allowlisted users and/or service token.
- Party app uses read-only allowlisted tool calls.
Phase 1 Goal
Stand up a secure, testable path from the existing Pathfinder stack (pathfinder-experience / P2E_Buddy / Quartz pipeline) → Foundry MCP for read-only queries only.
Success looks like:
- Endpoint reachable only through Cloudflare Access.
- Unauthenticated requests blocked.
- Authenticated request succeeds.
- Tool surface inventoried and classified for safety.
Prerequisites
- GM host can run
cloudflared. - Domain in Cloudflare (or subdomain under your existing setup).
- Foundry +
foundry-vtt-mcpalready running locally. - Agreement that Phase 1 is read-only discovery/testing.
Phase 1 Checklist (Operator Runbook)
1) Verify local MCP bind (must be private)
- Confirm current listening socket:
ss -ltnp | grep -E 'foundry|mcp|8787|3000'
- Requirement:
- Service binds to
127.0.0.1:<port>(preferred), not0.0.0.0.
- Service binds to
If needed, reconfigure foundry-vtt-mcp to localhost bind before continuing.
2) Install and authenticate Cloudflare Tunnel client
(Commands vary slightly by distro; example flow)
- Install cloudflared
- Login once:
cloudflared tunnel login
This opens browser auth to the GM’s Cloudflare account/team.
3) Create tunnel + DNS route
Example:
cloudflared tunnel create foundry-mcpcloudflared tunnel route dns foundry-mcp mcp-foundry.<your-domain>
Record tunnel UUID and generated credentials file path.
4) Configure ingress to localhost MCP
Create/update config (typical path /etc/cloudflared/config.yml):
tunnel: foundry-mcp
credentials-file: /etc/cloudflared/<TUNNEL-UUID>.json
ingress:
- hostname: mcp-foundry.<your-domain>
service: http://127.0.0.1:<MCP_PORT>
- service: http_status:404Start/enable:
sudo systemctl enable --now cloudflared
5) Add Cloudflare Access policy (hard gate)
In Cloudflare Zero Trust:
- Create Access application for
mcp-foundry.<your-domain>. - Default action: deny.
- Allow only:
- specific emails (GM + you), and/or
- service token for app backend.
- Set short session duration and require re-auth.
Recommended: use service token for machine-to-machine app adapter.
6) Validate edge protection
Checks:
- From incognito/no auth, hit endpoint → should be blocked by Access.
- From authorized identity, endpoint should respond.
- Check Cloudflare Access logs show allow/deny events.
If unauthenticated access works, stop and fix before proceeding.
7) Tool surface inventory (read-only recon)
From authorized client:
- List available MCP tools/resources.
- Export list into a local note.
- Classify each item:
SAFE_READSENSITIVE_READPROHIBITED(write/mutate/admin/spoiler-heavy)
Output artifact to create in ideas folder:
01_P2E_MCP/Foundry_MCP_Tool_Allowlist_Draft.md
8) Define temporary allowlist for Phase 1 app tests
Allow only minimal read endpoints needed for validation, e.g.:
- system/world metadata
- actor read
- encounter/initiative read
Block everything else at adapter layer (even if server exposes more).
9) Smoke test from app adapter
Run three test prompts through adapter:
- “What is current initiative order?”
- “What conditions are on party members?”
- “Summarize current encounter state (player-safe).”
Acceptance:
- Responses return quickly.
- No GM-only notes/spoilers leak.
- Source tags added (
foundry-live).
10) Phase 1 exit criteria
All must pass:
- No direct public access to localhost MCP.
- Access policy enforced and logged.
- Tool inventory completed.
- Draft allowlist written.
- Smoke tests pass with no spoiler leak.
If any fail, do not advance to wider pilot.
Risk Notes (Phase 1)
- Biggest risk is exposing overly broad read scope, not just write scope.
- Journals/scenes can contain GM-only content; default to blocked until verified.
- Keep adapter as policy enforcement point; do not trust client behavior.
Recommended Next File (Phase 2 prep)
Create after Phase 1 completion:
01_P2E_MCP/Phase_2_Spoiler_Safety_and_Adapter_Policy.md
Include:
- final tool allowlist
- spoiler test cases
- credential rotation + incident steps