Skip to main content
Glama
Sign In
Cloudflare Workers MCP Server

Cloudflare Workers MCP Server

by daniil-shumko
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Deploy Preview

deploy_preview

Deploy a preview of an existing Worker without touching production, returning a stable per-preview URL. Re-deploying the same preview name updates it in place.

Instructions

Deploy a preview of an existing Worker without touching production: either a static-site directory (assets) or Worker code (modules). Returns a stable per-preview URL (https://-..workers.dev) and a per-deployment URL. Re-deploying the same preview_name updates that preview. Uses the beta Worker Previews API.

Input Schema

NameRequiredDescriptionDefault
modulesNoWorker code: modules, each with inline content or a local file path; the first is the entry point unless main_module says otherwise
bindingsNoBindings for the preview (modules mode)
directoryNoStatic site: path to the built site directory (same handling as deploy_static_site)
main_moduleNoEntry-point module name (default: first module)
script_nameYesThe existing Worker to preview (deploy production first)
preview_nameYesPreview name, e.g. a branch name. An existing preview with this name is reused, so its stable URL stays the same across deploys.
html_handlingNoHow HTML URLs are canonicalized (default: auto-trailing-slash)
compatibility_dateNoYYYY-MM-DD; defaults to the Worker's current compatibility date
not_found_handlingNoResponse when no asset matches: 'single-page-application' serves /index.html (SPA mode), '404-page' serves /404.html (default: none)
compatibility_flagsNoRuntime compatibility flags
enable_preview_urlsNoTurn on the Worker's preview URLs (subdomain previews_enabled) if they are off. Without it previews deploy but aren't routable. Default true. Production workers.dev serving is never changed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.4.0

TDQS

A4.2/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations declare a non-destructive, non-read-only, open-world write; the description adds real value beyond that by disclosing the beta API, the stable per-preview URL format, the per-deployment URL, and the update-on-redeploy semantics. It stops short of noting permission/auth requirements or that preview URLs may need enable_preview_urls to be routable (that implication lives only in the schema).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences, no repetition, front-loaded with the action and the mode choice, then return values, then re-deploy behavior. Every sentence adds information the agent needs.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter deploy tool with no output schema, the description covers the action, mode selection, return shape, and re-deploy semantics, which is most of what an agent needs. Missing are prerequisites like required API scope and the dependency on enabling preview URLs, which affect whether the call succeeds.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3. The description does add one genuinely useful clarification the schema lacks — that 'directory' and 'modules' are the two mutually exclusive input modes — but the remaining 9 parameters get no treatment beyond their own descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Deploy a preview of an existing Worker') plus the two supported modes (static-site directory/assets vs Worker code/modules), which immediately separates it from deploy_worker and deploy_static_site. The 'without touching production' clause pins the scope further.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clear when-to-use context: preview-only, existing Worker, re-deploy with the same preview_name to update. The prerequisite that the Worker must already exist is carried in the schema ('deploy production first') rather than the description, and no explicit alternative (deploy_worker, deploy_static_site, list_previews) is named as a fallback.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools