How It Works

Invoker connects Claude to a deployment pipeline. You describe what you want in natural language, and the system handles everything from HTML generation to live hosting and form capture.

Architecture overview

You <-> Claude <-> MCP Server (stdio) <-> Invoker API <-> Cloudflare KV + Supabase
                                              |
                                        slug.invoker.page

Step by step

1. You talk to Claude

You open a Claude conversation (Claude Desktop, Claude Code, or any MCP-compatible client) with the Invoker MCP server installed. You describe what you want in plain English:

"Build me a waitlist page for my new app and deploy it"

2. Claude calls MCP tools

Claude selects the appropriate Invoker tools -- use_template, deploy, get_submissions, etc. -- and calls them over the stdio transport. The MCP protocol handles serialization and transport between Claude and the Invoker MCP server running on your machine.

3. MCP server calls the Invoker API

The MCP server translates tool calls into HTTPS requests to the Invoker API at api.invoker.page. It attaches your API key from ~/.invoker/credentials.json (or the INVOKER_API_KEY environment variable) and sends the request.

MCP tool: deploy({ html: "...", slug: "my-waitlist" })
    -> POST https://api.invoker.page/deploy
       Authorization: Bearer inv_xxxxx
       Body: { "html": "...", "slug": "my-waitlist" }

4. API stores the deployment

The Invoker API is a Cloudflare Worker. On deploy, it does two things:

• Cloudflare KV -- stores the HTML content keyed by {slug}/index.html for fast edge serving
• Supabase Postgres -- stores deployment metadata (owner, slug, status, timestamps, settings)

Any placeholders in the HTML are replaced with the real submission endpoint before storage.

5. Sites are served via wildcard subdomains

Every deployment is accessible at slug.invoker.page. Wildcard DNS on *.invoker.page routes all subdomain requests to the same Cloudflare Worker. The worker extracts the subdomain from the hostname, looks up {slug}/index.html in KV, and serves the HTML.

6. Form submissions are captured

When a visitor fills out a form on a deployed page, the browser POSTs to https://api.invoker.page/submit/{deployId}. The API:

1. Validates the submission (checks honeypot, rate limit)
2. Stores the data in Supabase Postgres
3. Fires any configured webhooks (generic or Slack)
4. Sends an email notification if enabled

Submissions are then retrievable through Claude (via the get_submissions tool) or the HTTP API.

Infrastructure

Component	Role
Cloudflare Worker	API server, HTML serving, edge routing
Cloudflare KV	HTML content storage, low-latency reads
Supabase Postgres	User accounts, deployment metadata, submissions, webhooks
Wildcard DNS	Routes *.invoker.page to the Cloudflare Worker

What runs where

Location	What happens
Your machine	MCP server process (stdio), credential storage
Cloudflare edge	API request handling, HTML serving, rate limiting
Supabase	Data persistence, authentication state
Browser	Login flow (email + OTP verification)