Cloudflare Workers MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| CLOUDFLARE_API_TOKEN | Yes | API token with Workers Scripts: Edit permission | |
| CLOUDFLARE_ACCOUNT_ID | Yes | Cloudflare account ID from dashboard |
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
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_workersA | List all Worker scripts in your account. Returns each Worker's name, timestamps, and whether it serves static assets. |
| get_workerA | Get a Worker's settings (bindings, compatibility date and flags, placement, observability) plus its cron triggers and workers.dev subdomain status. |
| get_worker_codeA | Download a Worker's deployed source code. Module-syntax Workers return one entry per module; service-worker-syntax Workers return a single script. |
| deploy_static_siteA | Deploy a local directory as a static site on Workers (assets-only Worker): builds the file manifest, uploads only files Cloudflare doesn't already have, and deploys. Newly created sites are served on workers.dev. Set not_found_handling to 'single-page-application' for SPAs. _headers/_redirects at the directory root are applied as configuration (not uploaded), and .assetsignore rules (gitignore-style) exclude files from the deploy. |
| redeploy_assetsA | Create a new deployment of an assets-only Worker that reuses its previously uploaded files (keep_assets) — useful to change html_handling or not_found_handling without re-uploading the site. |
| deploy_workerA | Upload and deploy a Worker script (ES modules) with optional bindings (plain_text, secret_text, kv_namespace, r2_bucket, d1, assets). Replaces the Worker's code and binding set if it already exists. Set keep_assets to retain a site's static assets while updating code. By default the Worker is served on workers.dev. |
| delete_workerA | Permanently delete a Worker script, including its versions, deployments, and any static assets. Set force to delete even when other resources depend on it. |
| update_worker_settingsA | Update a Worker's settings (bindings, compatibility date/flags, logpush, observability) without re-uploading its code. Note: bindings REPLACE the Worker's full binding set. |
| list_versionsA | List a Worker's versions (newest first): version ID, number, author, source, and deploy message. Versions are immutable snapshots; use list_deployments to see which are live. |
| list_deploymentsA | List a Worker's deployments (newest first). Each deployment maps traffic percentages to one or more versions; the newest deployment is the live one. |
| get_versionA | Get a Worker version's detail: bindings, compatibility date/flags, handlers, and usage model for that immutable snapshot. |
| create_versionA | Upload a new Worker version WITHOUT deploying it — live traffic is unchanged until the version is referenced by create_deployment. Use for staged rollouts. |
| create_deploymentA | Point live traffic at Worker versions: a single version at 100%, or a gradual rollout splitting traffic across two versions (e.g. 90/10). Percentages must sum to 100. |
| rollback_workerA | Roll a Worker back by deploying an older version at 100% traffic. Only the 100 most recent versions are eligible; bound resources (KV, R2, D1 data) are NOT reverted. |
| get_cron_triggersA | Get a Worker's cron triggers (scheduled events). |
| list_worker_domainsA | List custom domains attached to Workers in this account. Optionally filter by Worker name, hostname, or zone. |
| add_worker_domainA | Attach a custom domain to a Worker. The domain's zone must be active in this Cloudflare account (external zones are not supported); Cloudflare creates the DNS record and certificate automatically. |
| delete_worker_domainA | Detach a custom domain from its Worker. The hostname stops routing to the Worker (and its previews). |
| set_workers_devA | Enable or disable serving a Worker on its ..workers.dev subdomain, and optionally version preview URLs. |
| set_cron_triggersA | Replace a Worker's full cron trigger set (the Worker must export a scheduled handler). Pass an empty list to remove all triggers. |
| query_worker_logsA | Query a Worker's logs (Workers Logs / observability). Returns the most recent matching events with message, outcome, request, and timing. The Worker must have observability enabled (deploy_worker's enable_observability or update_worker_settings). |
| health_checkA | Verify the API token is valid and connection to Cloudflare is working. Useful for troubleshooting authentication issues. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 22 tools
Most tools target distinct resources/actions, but there is potential confusion between deploy_worker, create_version, create_deployment, and rollback_worker since they all relate to deployment lifecycle. Similarly, get_worker, get_worker_code, and get_version could be mixed up, though descriptions clarify the differences.
The naming pattern is largely consistent verb_noun (e.g., deploy_worker, list_versions, set_cron_triggers). Minor deviations include health_check (a noun phrase) and set_workers_dev (unusual phrasing), but these do not undermine overall predictability.
With 22 tools, the server is slightly heavy but still well-scoped for the breadth of Cloudflare Workers functionality. Each tool covers a distinct aspect, though a few could be consolidated (e.g., deployment-related commands) to reduce count.
The tool surface is comprehensive, covering Worker CRUD, version/deployment management, domain attachments, cron triggers, logs, settings, and static site deployment. No significant gaps are apparent for typical Workers workflows.