Skip to main content
Glama
Sign In
mcp-cloud-deploy

mcp-cloud-deploy

by hoangtrietdev
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Local

deploy_to_cloudflare_pages

Deploy built static sites or React/Vite SPAs to Cloudflare Pages, with optional custom-domain and DNS setup, or use the ready pages.dev URL when no domain is owned.

Instructions

Deploy a static website to Cloudflare Pages. Supports landing pages with nested image/assets and React/Vite single-page apps. If domain is omitted, the deployment URL works without owning a domain; if provided, bind it and configure Cloudflare DNS when possible.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "project_name": "<project_name>",
      "dir_path": "<dir_path>"
    },
    "name": "deploy_to_cloudflare_pages"
  }
}

Input Schema

NameRequiredDescriptionDefault
branchNoDeployment branch; defaults to main.main
domainNoOptional custom domain to bind after deployment, for example www.example.com. Omit if you do not own a domain; the pages.dev URL is ready to use.
dir_pathYesAbsolute or relative path to the built static directory, which must contain index.html.
spa_modeNoEnable for React/Vite apps using client-side history routes. Adds a Cloudflare Pages fallback to index.html. Leave false for traditional multi-page static sites.
project_nameYesCloudflare Pages project name.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv1.0.0

TDQS

B3.4/5.0
Behavior3/5

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

With no annotations, the description carries the full load: it discloses that domain binding is best-effort ('configure Cloudflare DNS when possible'), which usefully tells the agent DNS may not succeed. It does not disclose whether redeploying to an existing project_name overwrites the prior deployment, what authentication is required, or what the call returns.

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

Conciseness4/5

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

Three sentences, front-loaded with the core action, and each one carries a distinct piece of information (capability, supported project shapes, domain behavior). No filler, though the sentence structure is somewhat list-like rather than organized around invocation decisions.

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

Completeness3/5

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

For a 5-parameter mutation tool with no annotations and no output schema, the description covers the two deployment shapes and the optional-domain path. It omits what the agent receives back (presumably a deployment URL), failure modes, and whether repeated deploys update or conflict with an existing project, leaving gaps an agent would want filled.

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 description coverage is 100%, so the baseline is 3. The description restates the domain trade-off already in the schema and gestures at spa_mode via 'React/Vite single-page apps', but adds no format or constraint detail beyond what the schema already provides.

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

Purpose4/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 static website to Cloudflare Pages') and narrows scope with two supported project types (nested-asset landing pages, React/Vite SPAs). It does not name the sibling attach_custom_domain even though the domain-binding behavior overlaps with it, so the boundary between the two is left implicit.

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

Usage Guidelines3/5

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

The domain sentence gives conditional guidance ('If domain is omitted... if provided, bind it...'), which is genuine when-to-use context for one parameter. There is no guidance on when to use this tool versus attach_custom_domain for domain work, nor any stated prerequisites such as existing credentials or a pre-built directory.

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