---
name: cloudflare-worker-connect
description: '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.'
metadata:
  icon: ':simple-icons:cloudflare:'
  title: Cloudflare Worker Connect
  packageName: '@alwaysmavs/cloudflare-worker-connect'
  version: 0.0.1
---

# 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:

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

### List Worker Scripts

Use `cloudflare_worker.list_worker_scripts`.

```bash
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`.

```bash
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`.

```bash
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`.

```bash
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`.

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

Minimal payload shape:

```json
{
  "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`.

```bash
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`.

```bash
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`.

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

Minimal payload shape:

```json
{
  "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