cloudfact
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLOUDFACT_HOME | No | Override the directory for state (defaults to ~/.cloudfact). | |
| CLOUDFLARE_API_TOKEN | No | Cloudflare API token for authentication. Can be used instead of `cloudfact login`. | |
| CLOUDFLARE_ACCOUNT_ID | No | Your Cloudflare account ID, used with CLOUDFLARE_API_TOKEN. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| deployA | Publish a folder (or a single .html file) from this machine to a public Cloudflare URL. "tunnel" backend (default when signed out): local static server + cloudflared quick tunnel, *.trycloudflare.com URL; the process runs in the background and outlives the session. "workers" backend (default when signed in): Cloudflare Workers with static assets, fixed URL https://..workers.dev; redeploying updates the same address. Idempotent on tunnel: if the same path is already live, returns the existing URL (reused=true). Deploys are PRIVATE by default on both backends (key-gated link; on workers a gate Worker runs in front of the files); pass public=true to publish openly. access=[emails] (workers backend, API-token login) puts Cloudflare Access in front instead: visitors sign in with a one-time email code and only listed emails get in. Returns JSON with url and, when private, privateUrl (already includes #key=...). |
| exposeA | Publish an app that is already listening on a port to a public *.trycloudflare.com URL (tunnel backend). Without ssh, the port is on this machine. With ssh (user@host), the app runs on another machine: cloudfact opens an SSH port-forward to it and publishes through here — nothing to install remotely (key-based SSH access required). HTTP and WebSocket traffic is proxied. Apps are PRIVATE by default (same #key gate as static deploys, with rate limiting and optional expiry); pass public=true to publish without the gate. Idempotent: the same port/host already live returns the existing URL (reused=true). |
| listA | List every cloudfact deploy with backend, status and URL. |
| catalogA | Every cloudfact in the user's Cloudflare account, grouped by project, as the account itself sees them (so deploys made from another machine show up too). Each entry says whether it is public, a private key link or behind Cloudflare Access sign-in, and whether it serves static files or an app with its own server. Quick tunnels have no account-side resource and appear only when this machine still has their record (inAccount=false). publish=true turns the catalog into a browsable page and returns its URL; that page asks for Cloudflare Access sign-in by default, for the email that owns the account. |
| projectA | File a deploy under a project in the account catalog (or pass project=null to clear it). Takes effect without redeploying. |
| credentialsA | Record how to get into the app behind a deploy (its own username/password/note, not cloudfact's). Stored with the deploy on this machine and shown only on a catalog page that is itself behind Cloudflare Access sign-in. Pass creds=null to clear. Never put the user's secrets in your reply. |
| statusA | State of one deploy, including an HTTP check of its public URL (reachable/httpStatus). |
| rotateA | Issue a new private key for a live tunnel deploy without restarting it: the previous link and all sessions stop working at once. Optionally set an expiry. On a public deploy this turns it private. Returns the new privateUrl. |
| powerA | Turn a cloudfact off, or back on. Off: its link stops answering (a Workers deploy loses its workers.dev address; a tunnel answers with a "this page is off" page) but nothing is deleted, so on=true brings the very same link back, with the same key and sign-in. Deploying it again also turns it on. Prefer this over remove when the user wants something "off" or "down" rather than gone. The catalog page behind sign-in has the same switch on every card. |
| stopA | Stop the local server and tunnel of one deploy (or all of them with all=true). The record is kept for inspection. Not applicable to the workers backend. |
| removeA | Stop (if running) and delete the deploy record and logs. On the workers backend, also deletes the worker on Cloudflare. |
| logsA | Last lines of the deploy logs: host (local server), cloudflared and wrangler. |
| doctorB | Diagnostics: cloudflared, Cloudflare sign-in, default backend and active deploys. Run it before deploy when something fails. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| cloudfact | Publish a path from this machine and return the URL |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 13 tools
Several tools have overlapping-ish territory: list vs catalog (local records vs account-wide), stop vs power vs remove (three ways to make a deploy 'not running'), and deploy vs expose (two publish paths). The detailed descriptions do clarify the boundaries (e.g. 'prefer power over remove'), but an agent must read carefully to avoid misselection.
All names are single lowercase words, which is at least uniformly styled, but there's no predictable verb/noun convention: some are verbs (list, stop, expose, deploy, rotate) and some are nouns (catalog, project, credentials, status, logs, doctor). Readable but no coherent pattern to infer intent from name alone.
13 tools is a reasonable scope for a deploy/tunnel/workers management server, and most map to distinct lifecycle operations. Slightly heavy with some closely related operations (stop/power/remove), but each earns its place.
Strong lifecycle coverage: deploy, expose, status, logs, stop, remove, power off/on, rotate keys, project filing, credentials, account catalog, and diagnostics. Minor gaps like a bulk redeploy/update-content primitive, but core create-inspect-modify-teardown workflows are all present.