AI Workflow MCP

Sign in

Docs

Cloudflare Architecture

How AI Workflow MCP stores, serves, and refreshes facts.

AI Workflow MCP production is Cloudflare-native.

Runtime

  • apps/worker-mcp: MCP JSON-RPC, REST list/detail/search endpoints, key authentication, usage logging, and health checks.
  • apps/worker-ingest: source scheduling, Queue consumption, and source refresh.
  • apps/worker-docs: status Worker for status.aiworkflowmcp.com.
  • apps/web: product site and authenticated account/API-key surface through OpenNext on Workers.
  • docs: Fumadocs documentation site through OpenNext on Workers.

Storage

  • D1 aiworkflowmcp-v2-core: structured catalog rows, search rows, framework rows, source status, API keys, and usage logs.
  • R2 aiworkflowmcp-v2-evidence: raw source payloads, evidence JSON, full Markdown, and exports.
  • R2 aiworkflowmcp-web-opennext-cache: public web incremental cache.
  • Queue aiworkflowmcp-v2-source-jobs: source refresh work queue.
  • KV CATALOG_CACHE: short-lived catalog and health cache.

Source Freshness

Source fetches produce content hashes. When a source hash changes, matching public rows are marked stale until the parser rebuilds and verifies the facts. /health returns degraded when stale facts, source errors, unknown hashes, or failed quality checks are visible.

Account And Key Path

The production web app owns user sessions and API key creation. Clerk protects /:locale/account/*, and the API key page writes hashed keys into D1. The MCP/API Worker validates keys by hashing the presented secret and comparing it to the stored hash.

Authenticated requests are still served by the same Cloudflare Worker path as public requests. The key changes quota scope, usage logging, and account-level history; it does not route users to a separate infrastructure stack.

Deployment Boundary

Do not add Neon, Prisma Postgres, PM2, Caddy, Upstash, Vercel Blob, Stripe, or Resend back into the active request path unless the architecture is intentionally redesigned.