Back to Skills

Cloudflare Worker Connect

cloudflare-worker-connect

Inspect and manage existing Cloudflare Workers through the OOMOL Connect Cloudflare Worker API. Use when the user asks to list, search, read, audit, patch settings, or manage secret_text bindings for Cloudflare Worker scripts, especially when combining Cloudflare official skill guidance with authenticated Connect actions.

SKILL.md

Cloudflare Worker Connect

When to Use

Use this skill when the user wants to inspect or manage existing Cloudflare Workers through the authenticated OOMOL Connect API, especially for requests such as:

  • list or search Worker scripts in the connected Cloudflare account
  • read a Worker script’s deployed source
  • inspect Worker metadata, bindings, compatibility settings, tags, observability, limits, migrations, or tail consumers
  • list or check Worker secret binding metadata
  • add or replace a secret_text binding
  • patch Worker settings without hand-writing Cloudflare REST API calls
  • combine Cloudflare’s official agent guidance with Connect-backed account operations

Cloudflare’s official agent skill is cloudflare/skills (https://github.com/cloudflare/skills). Its main skill is named cloudflare, and it includes focused skills such as wrangler, agents-sdk, durable-objects, and others. Use that official guidance for Workers architecture, Wrangler project setup, deployment workflows, current limits, binding syntax, and Cloudflare documentation retrieval. Use the Connect actions below for authenticated operations against the user’s actual Cloudflare account.

This Connect skill does not deploy or upload Worker source code. If the user asks to build or deploy a Worker, use Cloudflare/Wrangler guidance for code and deployment, then use this skill only for post-deploy inspection, settings patches, or secret management that the exposed Connect actions support.

Runtime Inputs

Required inputs depend on the operation:

  • Listing scripts: no required user input. Optional page and perPage default safely to 1 and a small page size such as 20.
  • Searching scripts: ask for either a Worker script name or exact script tag id if neither can be inferred from the conversation.
  • Reading script content, settings, or secrets: require scriptName.
  • Getting one secret: require scriptName and secretName.
  • Adding or replacing a secret: require scriptName, secret name, and secret text. Never invent or infer secret values.
  • Patching settings: require scriptName plus at least one setting field to change. If the requested change could overwrite existing bindings, first read the current settings and construct the full intended bindings array.

Confirm with the user before running any mutating action: put_worker_script_secret or patch_worker_script_settings.

Execution

All actions use the connector service cloudflare_worker. Do not rediscover the connector at runtime.

Use --json and read the useful result from the data object. A representative observed response envelope is:

{
  "data": {},
  "meta": {
    "executionId": "...",
    "actionId": "cloudflare_worker.list_worker_scripts"
  }
}

List Worker Scripts

Use cloudflare_worker.list_worker_scripts.

oo connector run "cloudflare_worker" \
  --action "list_worker_scripts" \
  --data '{"page":1,"perPage":20}' \
  --json

Payload fields:

  • page: optional positive integer.
  • perPage: optional positive integer.

Useful result fields:

  • data.scripts[]
  • data.scripts[].name
  • data.scripts[].scriptTag
  • data.scripts[].createdOn
  • data.scripts[].modifiedOn
  • data.scripts[].compatibilityDate
  • data.scripts[].compatibilityFlags
  • data.scripts[].entrypoint
  • data.scripts[].handlers
  • data.scripts[].serviceName
  • data.scripts[].environmentName
  • data.scripts[].tags
  • data.resultInfo when present

Search Worker Scripts

Use cloudflare_worker.search_worker_scripts.

oo connector run "cloudflare_worker" \
  --action "search_worker_scripts" \
  --data '{"name":"my-worker","page":1,"perPage":20}' \
  --json

Payload fields:

  • name: optional Worker script name search.
  • id: optional exact Worker script tag search.
  • orderBy: optional, one of created_on, modified_on, or name.
  • page: optional positive integer.
  • perPage: optional positive integer.

Provide either name or id unless the user explicitly wants a broad list. Useful result fields are the same as list_worker_scripts.

Get Worker Source Content

Use cloudflare_worker.get_worker_script_content.

oo connector run "cloudflare_worker" \
  --action "get_worker_script_content" \
  --data '{"scriptName":"my-worker"}' \
  --json

Payload fields:

  • scriptName: required non-empty Worker script name.

Useful result fields:

  • data.content: raw deployed Worker source content.
  • data.contentType: Cloudflare response content type, or null.

When reporting source content, summarize or quote only the relevant portions unless the user explicitly asks for the full source.

Get Worker Settings

Use cloudflare_worker.get_worker_script_settings.

oo connector run "cloudflare_worker" \
  --action "get_worker_script_settings" \
  --data '{"scriptName":"my-worker"}' \
  --json

Payload fields:

  • scriptName: required non-empty Worker script name.

Useful result fields:

  • data.settings.bindings
  • data.settings.compatibilityDate
  • data.settings.compatibilityFlags
  • data.settings.logpush
  • data.settings.observability
  • data.settings.placementMode
  • data.settings.tags
  • data.settings.tailConsumers
  • data.settings.usageModel
  • data.settings.limits
  • data.settings.migrations

Patch Worker Settings

Use cloudflare_worker.patch_worker_script_settings.

oo connector run "cloudflare_worker" \
  --action "patch_worker_script_settings" \
  --data @payload.json \
  --json

Minimal payload shape:

{
  "scriptName": "my-worker",
  "compatibilityDate": "2026-05-11",
  "compatibilityFlags": ["nodejs_compat"],
  "observability": { "enabled": true },
  "tags": ["production"]
}

Payload fields:

  • scriptName: required non-empty Worker script name.
  • Optional patch fields: bindings, compatibilityDate, compatibilityFlags, logpush, observability, placementMode, tags, tailConsumers, usageModel, limits, and migrations.

bindings is the full bindings array to set on the script. Before changing bindings, read current settings with get_worker_script_settings, preserve bindings the user did not ask to remove, and show the intended binding names and types in the confirmation. Do not patch broad free-form fields unless the user has approved the exact intended change.

Useful result fields are under data.settings, with the same shape as get_worker_script_settings.

List Worker Secret Bindings

Use cloudflare_worker.list_worker_script_secrets.

oo connector run "cloudflare_worker" \
  --action "list_worker_script_secrets" \
  --data '{"scriptName":"my-worker"}' \
  --json

Payload fields:

  • scriptName: required non-empty Worker script name.

Useful result fields:

  • data.secrets[]
  • data.secrets[].name
  • data.secrets[].type
  • data.secrets[].text: redacted or null; never treat this as the usable secret value.
  • data.resultInfo when present

Report secret names and types, not secret values.

Get One Worker Secret Binding

Use cloudflare_worker.get_worker_script_secret.

oo connector run "cloudflare_worker" \
  --action "get_worker_script_secret" \
  --data '{"scriptName":"my-worker","secretName":"API_TOKEN"}' \
  --json

Payload fields:

  • scriptName: required non-empty Worker script name.
  • secretName: required non-empty secret binding name.

Useful result fields:

  • data.secret.name
  • data.secret.type
  • data.secret.text: redacted or null; never print as a secret value.

Add or Replace a secret_text Binding

Use cloudflare_worker.put_worker_script_secret.

oo connector run "cloudflare_worker" \
  --action "put_worker_script_secret" \
  --data @payload.json \
  --json

Minimal payload shape:

{
  "scriptName": "my-worker",
  "name": "API_TOKEN",
  "text": "<secret value>",
  "type": "secret_text"
}

Payload fields:

  • scriptName: required non-empty Worker script name.
  • name: required non-empty secret binding name.
  • text: required secret value.
  • type: optional; if supplied it must be secret_text.

For secret values, prefer --data @payload.json over inline shell JSON so the value is not exposed in shell history or process listings. Do not print the payload. After success, report only data.secret.name and data.secret.type; do not report data.secret.text.

Result Handling

For read-only operations, report the concise account facts the user asked for: script names, modified timestamps, compatibility settings, binding summaries, secret binding names, or targeted source excerpts. Include the connector action used when it helps the user understand where the result came from.

For mutating operations, report:

  • the action run
  • the Worker script name
  • the exact settings or secret binding names changed
  • the useful returned field path, such as data.settings or data.secret.name

Do not claim deployment success from this skill. It can patch settings and secret bindings, but it does not upload Worker source or run wrangler deploy.

Failure Handling

Stop and explain the blocker when:

  • the connector reports authentication or permission failure; ask the user to reconnect or grant the needed Cloudflare API token scopes in Connect
  • the user asks to deploy/upload Worker source; route to Cloudflare/Wrangler workflow instead because no deploy action is exposed here
  • scriptName is missing for script-specific operations
  • a search by name returns multiple scripts and the requested mutation would be ambiguous
  • a settings patch would overwrite bindings or free-form fields whose current values were not inspected
  • the user asks to reveal an existing secret value; Cloudflare returns redacted metadata, so only replacement is supported
  • schema validation rejects a payload field; remove unsupported fields rather than guessing Cloudflare REST API parameters
  • the connector returns no data object or no expected field path; report the observed envelope and do not invent a result