Skip to main content
Glama
gabrielchaves6

cloudfact

by gabrielchaves6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Publish static site

deploy
Idempotent

Publish a local folder or HTML file to a public Cloudflare URL, with optional key-gated privacy and Cloudflare Access for email-restricted sharing.

Instructions

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=...).

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNoDeploy name (slug). Defaults to the folder/file name
pathYesAbsolute path of the folder or .html file to publish
accessNoEmails allowed to sign in through Cloudflare Access (identity gate instead of the key link; workers backend)
publicNoPublish without the key gate (default false: private)
backendNoauto = workers when signed in to Cloudflare, otherwise tunnel
expiresNoPrivate key lifetime, e.g. "30m", "24h", "7d" (default: never expires)
restartNoRestart even if already live (yields a new URL on tunnel)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.8.8
    • addedInput schema / properties / access
      Added value: +{
+  "description": "Emails allowed to sign in through Cloudflare Access (identity gate instead of the key link; workers backend)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • removedInput schema / properties / private
      Removed value: -{
-  "description": "Key-protected: only whoever opens privateUrl (#key=...) sees the content. Forces the tunnel backend",
-  "type": "boolean"
-}
    • addedInput schema / properties / public
      Added value: +{
+  "description": "Publish without the key gate (default false: private)",
+  "type": "boolean"
+}
  2. First observedv0.5.0

TDQS

A4.6/5.0
Behavior5/5

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

Annotations declare readOnlyHint=false and idempotentHint=true, and the description elaborates on both: it explains the background process that outlives the session, the key-gated privacy default, the access control via Cloudflare Access, and the exact return JSON shape (url and privateUrl). It discloses far more than the annotations alone, which is essential for a mutating tool with security implications.

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?

The description is long (~150 words) but each sentence carries distinct value: it covers backends, idempotency, privacy, access control, and return format. It is front-loaded with the core purpose and then systematically explains behavior. While not terse, the density of information justifies the length.

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

Completeness5/5

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

For a tool with 7 parameters, two backends, and security nuances, the description covers all critical aspects: deployment behavior, idempotency, privacy, access control, expiration, and return JSON. It even notes the tunnel process runs in the background. There is no output schema, but the description explicitly states the JSON fields, making it complete for an agent to call correctly.

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

Parameters4/5

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

All 7 parameters have schema descriptions (100% coverage), but the description adds meaningful nuance: it clarifies the backend default based on sign-in status, the semantics of 'access' (only on workers, requires API-token login), and the effect of 'restart' (yields a new URL on tunnel). This goes beyond the schema's basic property descriptions, though it could be more explicit about edge cases like 'expires' on the workers backend.

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?

The description states a specific verb ('publish') and resource (a folder or .html file) and explains the two backends (tunnel vs workers) and their URL outcomes. It clearly distinguishes the tool's purpose from siblings like 'expose' by detailing the deployment mechanisms and idempotent behavior.

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?

The description provides clear context on when to use each backend (signed out vs signed in) and explains idempotent redeployment. It does not explicitly mention alternative tools or when to avoid using it, but the backend selection guidance effectively steers the agent toward the right invocation.

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