Skip to main content
Glama
gabrielchaves6

cloudfact

by gabrielchaves6
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Expose a running app

expose
Idempotent

Publish an app listening on a local or SSH-reachable port to a public trycloudflare.com URL, with private key-gated access by default and optional public sharing.

Instructions

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

Input Schema

NameRequiredDescriptionDefault
sshNoSSH destination of the machine running the app, e.g. ubuntu@10.0.0.5 or a Host alias from ~/.ssh/config
nameNoDeploy name (slug). Defaults to port-<port> or <host>-<port>
portYesPort the app listens on (locally, or on the SSH host)
accessNoEmails allowed to sign in through Cloudflare Access (identity gate and a fixed workers.dev URL instead of the key link)
publicNoPublish without the key gate (default false: private)
expiresNoPrivate key lifetime, e.g. "30m", "24h", "7d" (default: never expires)
restartNoRestart even if already live (yields a new URL)
sshPortNoSSH port (default 22)
identityNoPath to the SSH private key (default: ssh agent / ~/.ssh/config)
strictHostKeyNoRequire the SSH host key to be in known_hosts already (no first-connection trust)

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.11.1
    • addedInput schema / properties / access
      Added value: +{
+  "description": "Emails allowed to sign in through Cloudflare Access (identity gate and a fixed workers.dev URL instead of the key link)",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
  2. First observedv0.5.0

TDQS

A4.7/5.0
Behavior5/5

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

The annotations only declare readOnlyHint=false and idempotentHint=true, while the description adds substantial behavior: private key-gated access by default, rate limiting, optional expiry, HTTP/WebSocket proxying, key-based SSH requirements, no remote install, and idempotent reuse of an existing URL. No annotation contradiction is present.

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?

The description is dense but well front-loaded: it starts with the core publish action, then explains SSH mode, traffic type, privacy, and idempotency. Every sentence adds operational detail for a complex tool without unnecessary repetition.

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 complex exposure tool with no output schema and sparse annotations, the description covers purpose, SSH prerequisites, privacy controls, traffic proxying, and idempotent return behavior. It gives enough context for an agent to invoke the tool 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?

Schema coverage is 100%, so the schema already documents all 10 parameters. The description still adds meaningful semantics for ssh behavior, public bypass, and idempotent same-port/host reuse, though it does not elaborate on parameters like access, identity, or strictHostKey beyond what the schema says.

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 uses a specific verb and resource: publish an already-listening app to a public trycloudflare.com URL via a tunnel backend. It distinguishes this from static deploy by emphasizing an app already running on a port and the SSH port-forward mode.

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?

It clearly explains the two usage modes: without ssh the port is local, with ssh the app runs remotely and cloudfact forwards to it. It also states the private-by-default behavior and how to use public=true, but it does not explicitly name sibling alternatives such as deploy or stop.

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