remote-mcp-server-authless2
by PhilBarnett
README.md
# Building a Remote MCP Server on Cloudflare (Without Auth)
This business MCP server requires OAuth authentication on Cloudflare Workers. It implements the MCP 2026-07-28 specification while remaining compatible with legacy clients for ordinary tool calls.
## Get started:
[](https://deploy.workers.cloudflare.com/?url=https://github.com/cloudflare/ai/tree/main/demos/remote-mcp-authless)
This will deploy your MCP server to a URL like: `remote-mcp-server-authless.<your-account>.workers.dev/mcp`
Alternatively, you can use the command line below to get the remote MCP Server created on your local machine:
```bash
npm create cloudflare@latest -- my-mcp-server --template=cloudflare/ai/demos/remote-mcp-authless
```
## Customizing your MCP Server
To add your own [tools](https://developers.cloudflare.com/agents/model-context-protocol/protocol/tools/) to the MCP server, register each tool on the `McpServer` created in the `createServer()` function in `src/index.ts` using `server.registerTool(...)`.
## Privacy-safe WooCommerce cohort reporting
`get_sample_to_purchase_cohort` measures all-product or ZipGrip Fabric Sample to
qualifying-purchase conversion for caller-selected cohort dates and 7–365 day windows.
Use `product_scope: "all"` for the email scorecard or `product_scope: "zipgrip"` for
the narrower historical analysis. It
matches normalized billing email, phone and registered WooCommerce customer ID only
inside the Worker. The response contains aggregate cohort performance and
non-identifying WooCommerce order IDs, but never returns billing email, billing phone,
customer ID or a reusable customer key.
A sample order must contain one or more line items and every line item must be
identified as a sample. A qualifying purchase is a later commercial-status order over
A$20 that is not sample-only. The tool reports match coverage, matured and converted customers, conversion
rate, time to first purchase, purchase counts, gross revenue, refunds, net revenue and
revenue per matured sample customer. The analysis is read-only, respects the
1 July 2024 commercial-data boundary and is capped at 730 days per request.
This scoped tool replaces the former ZipGrip-only cohort tool while retaining its
analysis through `product_scope: "zipgrip"`; this keeps the MCP tool count unchanged.
## Reusable guarded product Performance Max builder
The reusable Google Ads workflow removes product-specific campaign code while
retaining paused-first safety. It remains fixed to Blindmotion customer
`6610097637`, Merchant Center `5320593492`, Australia and English.
- `preview_google_ads_product_pmax_paused` verifies the exact published
WooCommerce product, derives its canonical product URL and `gla_<product ID>`
Merchant Center item, rejects duplicate campaign names and runs the complete
Google Ads request with `validateOnly: true`.
- `create_google_ads_product_pmax_paused` repeats those checks and creates one
campaign, one asset group and a one-product listing partition, all PAUSED.
Final URL expansion is disabled and the budget is limited to A$5–A$50/day.
- `inspect_google_ads_product_pmax_asset_group` revalidates the WooCommerce
identity, campaign and asset-group IDs, canonical landing page, one-product
listing tree, live assets and completeness.
- `bootstrap_google_ads_product_pmax_asset_group_guarded` accepts reviewed text,
existing Google Ads assets or exact image URLs below Blindmotion's WordPress
uploads directory. It validates image bytes, dimensions, ratios and size,
then uses a `validateOnly` preflight before one atomic asset mutation.
- `link_google_ads_product_pmax_youtube_assets_guarded` safely adds reviewed
YouTube assets to the same validated paused asset group.
The generic workflow derives campaign and asset-group names from a constrained
campaign label, requires exact confirmation phrases for every write, and has no
generic activation method. Launch remains a separate reviewed operation because
exclusive product removal from existing Shopping/PMax partition trees can alter
live campaign eligibility.
The original ZipGrip-specific tools remain temporarily available for backwards
compatibility and post-launch inspection of the existing ZipGrip campaign.
## Reusable guarded Fabric Sample setup
The Fabric Sample workflow uses the existing `clone_product_as_draft_guarded`
tool to make a draft, hidden copy of any exactly identified sample product. The
live sample product is never used as the write target.
- `preview_product_fabric_sample_setup` accepts source and destination product
IDs/names plus the exact source fabric selector, destination product selector
and destination multi-select colour template field IDs. It validates a
one-to-one fabric-range/colour-field structure and returns source,
destination and deterministic plan SHA-256 hashes without writing.
- `apply_product_fabric_sample_setup_guarded` requires those exact hashes and
`CONFIRM APPLY FABRIC SAMPLE SETUP`. It appends one product choice, a
remapped fabric selector and multi-select colour swatches only to the named
draft/hidden destination. IDs and choice slugs are deterministically
remapped, all copied pricing is disabled, unrelated product data is verified,
and a failed write is rolled back to the exact original WAPF value.
No product IDs, product names, WAPF field IDs or fabric names are hardcoded in
the reusable setup tools. Publishing the completed sample product remains a separate guarded review decision.
The staging-only publication control below can perform that final status change
without giving the MCP any live publication capability.
## Guarded staging product publication
`set_staging_product_publication_guarded` changes only the `draft`/`publish`
status of one exactly identified product on the fixed Blindmotion staging origin.
It requires the expected product name, current status, catalogue visibility, WAPF
metadata ID and complete field-group SHA-256 plus the exact confirmation phrase
`CONFIRM STAGING PRODUCT PUBLICATION CHANGE`. Catalogue visibility and WAPF
content must remain unchanged. The tool verifies the result, attempts rollback
on failure and has no live-site target.
## Guarded ZipGrip Performance Max builder
The server includes two narrowly scoped Google Ads tools for customer `6610097637`:
- `preview_google_ads_zipgrip_pmax_paused` checks for a duplicate campaign and sends the complete request to Google Ads with `validateOnly: true`.
- `create_google_ads_zipgrip_pmax_paused` requires the exact confirmation phrase `CONFIRM CREATE PAUSED ZIPGRIP PMAX`, repeats validation, and atomically creates a paused campaign skeleton restricted to Merchant Center item `gla_1301`.
The campaign name, account, Merchant Center account, AU feed label, product item, Australia/English targeting, landing page, and paused statuses are fixed. Daily budget is limited to A$5–A$50. Final URL expansion is opted out, all non-ZipGrip products are excluded, and no activation tool is provided.
## Google Search Console reporting
The server includes read-only Search Console tools for the fixed URL-prefix property
`https://online.blindmotion.com.au/`. They report organic-search queries, landing pages,
query/page pairs, and daily clicks, impressions, CTR, and average position.
Search Console reuses `GA4_SERVICE_ACCOUNT_JSON` and requests only the
`webmasters.readonly` OAuth scope. Enable the Google Search Console API in the
same Google Cloud project and add the service account email as a user of the
Blindmotion Search Console property before calling these tools.
## Outdoor SEO page inspection
`inspect_outdoor_seo_pages` is a read-only diagnostic locked to the Outdoor Blinds
landing page and the Straight Drop and Zip Sided outdoor-blind products. It compares
stored WordPress/WooCommerce content with the final rendered HTML, reports search
metadata and headings, inventories relevant Elementor/SEO-plugin metadata, and flags
known duplicated, placeholder, or incorrect indoor-product template text. It cannot
change WordPress content or metadata.
`inspect_outdoor_seo_elementor_templates` is locked to the six Elementor documents
rendered by those outdoor pages. It reports their identities, display conditions,
heading tags, responsive visibility and suspicious widget content without exposing a
write path.
`apply_outdoor_seo_fixes_guarded` applies one fixed cleanup after exact hashes, product
identities and Elementor source values match the reviewed state. It removes only two
sections already hidden on every device, replaces known placeholder content, updates
the three locked outdoor products and attempts rollback if a write fails.
## ChatGPT Ads: official plugin and advanced controls
Use the official **ChatGPT Ads Manager** plugin for account discovery, campaigns,
ad groups, ads, creative uploads/previews, budgets, bidding, targeting, schedules,
activation/pause/archive, reporting, conversion diagnostics and audit history.
It accesses the existing account and campaign; this cleanup does not change them.
Only `manage_chatgpt_ads_advanced` remains in this MCP. Its 22 operations cover
account activation/pause, account-wide daily/dated spending limits, conversion
source/event-setting creation, landing-page crawler evidence and product-feed
maintenance/SSH SFTP setup. These are not exposed by the installed official plugin.
Use `action: "controls", mode: "describe"` for the exact catalog and schemas.
Reads use `mode: "read"`; writes require preview then apply with identical inputs
and a signed token valid for 15 minutes. Fixed account identity, AUD currency and
resource state are revalidated. Money is AUD micros: 1 AUD = 1,000,000 micros.
Mutations are not retried automatically. Installing controls does not authorize spending.
The encrypted Cloudflare `OPENAI_ADS_API_KEY` secret remains required for advanced
operations. Do not remove it or revoke the key as part of this cleanup. Credentials
are redacted and redirects blocked. Audience membership/upload controls and hotel
insights were removed as unused; customer audience uploads belong in Ads Manager web.
Refresh Blindmotion MCP after deployment: retired `manage_chatgpt_ads` and
`get_chatgpt_ads_report` names are not aliases. Google Ads summary/daily reporting
remains combined and unchanged. The MCP stays within its 95-tool ceiling.
Run `npm run test:chatgpt-ads` for advanced guard and Cloudflare runtime checks.
See [the overlap audit](docs/chatgpt-ads-plugin-overlap.md).
## Repository-scoped GitHub App
The Worker can authenticate as GitHub App `4894554`, installation `160530258`, using
the encrypted `GITHUB_APP_PRIVATE_KEY` Cloudflare secret. Every installation token is
further restricted to repository ID `1359135665`
(`PhilBarnett/remote-mcp-server-authless2`) and expires automatically.
- `get_blindmotion_github_app_status` verifies the installation without exposing a
credential or token.
- `get_blindmotion_mcp_source_file` reads only `src/index.ts` or `README.md` from
the exact current `main` commit and returns the blob SHA needed for review-safe
draft PR creation.
- `create_blindmotion_mcp_draft_pr_guarded` atomically creates a branch, commit and
draft PR from an exact reviewed `main` SHA. It can replace only `src/index.ts`
and/or `README.md`, checks each expected blob SHA, and cannot touch workflows,
dependencies or `main`.
- `inspect_blindmotion_mcp_pull_request` reports PR state and changed files but cannot
approve or merge.
No MCP tool can merge a PR or push directly to `main`. Production deployment remains
limited to the existing GitHub Actions workflow after an externally reviewed merge.
## Guarded TotalBlock featured image
`replace_totalblock_featured_image_guarded` is locked to draft product `9413`, verifies
the product identity and reviewed current featured attachment `6704`, uploads or reuses
one JPEG/PNG/WebP attachment, preserves the complete gallery and all other product
configuration, and records the prior featured attachment for rollback. It requires the
exact phrase `CONFIRM REPLACE TOTALBLOCK FEATURED IMAGE` and never deletes media.
`replace_totalblock_gallery_images_guarded` is locked to the reviewed five-image
TotalBlock state. It preserves featured attachment `9417`, replaces exactly the four
legacy outdoor gallery attachments with four distinct approved JPEG/PNG/WebP images,
records rollback data, verifies the complete product image order, and requires
`CONFIRM REPLACE TOTALBLOCK GALLERY IMAGES`.
## Reusable fabric collection media importer
The importer separates source-page extraction from WordPress writes and contains no
supplier, collection, colour or product IDs. Both tools accept all commercial
identities and the collection URL at runtime:
- `preview_fabric_collection_import` supports `linked_product_pages` for collection
indexes whose full-size images live on individual fabric pages, and
`sectioned_attribute_swatches` for a single page containing swatches grouped by
headings such as opacity. It returns a deterministic manifest and SHA-256 without
writing.
- `import_fabric_collection_media_guarded` rebuilds the live manifest and requires
its exact reviewed hash plus `CONFIRM IMPORT FABRIC COLLECTION`. It creates a
hierarchy in the site's existing attachment `media_folder` taxonomy, downloads
only validated public HTTPS JPEG/PNG/WebP images, and assigns searchable title,
alt text, caption and source information.
Attachment filenames include supplier, collection, optional variant and colour, so
same-named swatches in multiple opacities remain distinct. Preview results also expose
stable item keys derived at runtime. The guarded importer accepts optional include and
exclude key lists plus a batch offset and batch size; batches are capped at four items
so large collections can resume safely within Cloudflare Worker subrequest limits.
`inspect_fabric_collection_media_import` rebuilds the exact reviewed manifest and
reports selected swatches as present or missing without creating folders or media.
Existing attachment slugs are skipped, reruns are idempotent, private/local URLs and
unsafe redirects are rejected, and the importer has no media deletion or overwrite
path.
## Reusable guarded curtain configurator
`preview_curtain_product_configuration` builds a deterministic, non-writing plan for
replacing one draft product's placeholder WAPF fields with a manual-or-motorised
curtain configuration. Product identity, new name, dimensional limits,
configurations, fabric roles, collection names, swatch attachment IDs and filenames,
headings, stack directions, mounting, operation choices, motor brand, power, motor
position and controls are supplied at runtime. Curtain configuration and fabric
selection are placed first, followed by dimensions and hardware choices. Alpha or
other motor-specific fields appear only for caller-designated motorised operation
choices.
Curtain configuration, heading, mounting, stack direction and operation choices may
each supply verified WordPress attachment IDs and filenames. A complete imaged choice
set renders as WAPF image swatches; a set with no image inputs remains a text radio
group. Partial image sets are rejected. Every fabric and visual-choice attachment is
revalidated before the plan is returned.
A two-layer configuration may optionally specify `fixed_layer_headings` with
`front` and `rear` objects, each containing a fabric `role` and a
`heading_key` referencing a supplied heading option. The plan validates that
both roles occur exactly once in that configuration and each heading exists. For
such a configuration, the general Heading Style selector is hidden; a required,
single-choice Heading Arrangement records the explicit front/rear pair in the
order. Configurations without fixed headings keep the ordinary selectable
Heading Style. For example, a double curtain can specify a front sheer S-Fold
and rear blockout Knife Pleat without exposing an incompatible shared heading
choice. This is parameter-driven and does not hard-code a fabric, heading or
product ID.
`apply_curtain_product_configuration_guarded` rebuilds the same plan and requires the
exact original WAPF hash, plan hash and
`CONFIRM APPLY CURTAIN PRODUCT CONFIGURATION`. It replaces only the product name and
WAPF field group while forcing the product to remain draft and hidden. The slug,
descriptions, categories, images, unrelated metadata and base price are preserved.
The write is verified and the exact prior state is restored if verification fails;
the tool cannot publish a product.
The first configuration pass intentionally supports only explicit caller-supplied
fixed option adjustments. Dimension-based curtain, fabric, track, motor, freight and
installation formulas can be added after the customer-facing option logic is
reviewed without embedding supplier pricing or product IDs in the Worker.
## Product-option image swatches
The generic `upload_wapf_choice_visual_guarded` tool uploads one reviewed JPEG, PNG or WebP for an exact choice on a caller-supplied draft/hidden product. It checks the product name, WAPF hash, field ID, choice slug and supplied image SHA-256 before uploading; it does not change product options or delete media. Call it once per image and keep the returned WordPress attachment IDs and filenames.
The generic `apply_wapf_image_swatches_guarded` tool converts selected radio fields to image swatches using those existing attachments. It checks the exact product identity, WAPF metadata ID and prior hash, field and choice labels/slugs, attachment IDs and filenames. The only WAPF changes are the selected field types and their choices' image URLs/attachment IDs. Field IDs, choice slugs, labels, pricing expressions, conditional logic and unrelated product data remain unchanged. The product must stay draft/hidden. The write is verified and the previous WAPF field group is restored on verification failure. Both tools require `CONFIRM APPLY WAPF IMAGE SWATCHES` and cannot publish a product.
## Parameter-driven WAPF field reconfiguration
`preview_wapf_field_reconfiguration` validates a caller-supplied plan to remove
explicitly identified WAPF fields and replace the complete choices and conditional
logic of other explicitly identified fields. Product identity, metadata ID, current
field-group hash, field IDs and labels, choice labels/slugs/prices, condition groups
and every image are runtime inputs. Images may reference an existing WordPress
attachment with its expected filename or a public HTTPS JPEG/PNG/WebP locked to an
exact SHA-256 digest. The preview detects duplicate IDs/slugs, changed field types,
invalid pricing and any conditional reference orphaned by the plan. It performs no
writes.
`apply_wapf_field_reconfiguration_guarded` rebuilds the exact previewed plan and
requires its plan hash plus `CONFIRM APPLY WAPF FIELD RECONFIGURATION`. Hash-locked
remote images are imported idempotently, then only the selected product's WAPF field
group is updated. The product must be draft and hidden and cannot be published. The
result is verified against an exact post-write hash; if the write or verification
fails, the original WAPF field group is restored and verified. Product identity,
visibility, descriptions, images and all non-WAPF data remain untouched.
## Guarded WAPF image delivery optimisation
The generic WAPF image-delivery workflow reduces option-selector payload without
replacing or deleting original WordPress attachments.
- `preview_wapf_image_delivery_optimisation` accepts an exact draft/hidden product,
WAPF hash, runtime-selected image-swatch field IDs and labels, target maximum
dimension, offset and batch size. It selects the largest existing square WordPress
derivative at or below the requested size and returns a deterministic plan hash.
- `apply_wapf_image_delivery_optimisation_guarded` requires that exact plan plus
`CONFIRM APPLY WAPF IMAGE DELIVERY OPTIMISATION`. It changes only the selected
choice image URLs, preserves every non-empty attachment alt value and generates
option-derived alt text only when blank. It verifies the product and media and
attempts exact rollback on failure.
Batches are capped at ten choices to stay within Worker subrequest limits. Attachment
IDs, original files, WAPF fields, slugs, labels, pricing, conditions and unrelated
product data are preserved. Product IDs, names, field IDs, labels, image sizes and
batch boundaries are runtime parameters.
## Connect to Cloudflare AI Playground
You can connect to your MCP server from the Cloudflare AI Playground, which is a remote MCP client:
1. Go to https://playground.ai.cloudflare.com/
2. Enter your deployed MCP server URL (`remote-mcp-server-authless.<your-account>.workers.dev/mcp`)
3. You can now use your MCP tools directly from the playground!
## Connect Claude Desktop to your MCP server
You can also connect to your remote MCP server from local MCP clients, by using the [mcp-remote proxy](https://www.npmjs.com/package/mcp-remote).
To connect to your MCP server from Claude Desktop, follow [Anthropic's Quickstart](https://modelcontextprotocol.io/quickstart/user) and within Claude Desktop go to Settings > Developer > Edit Config.
Update with this configuration:
```json
{
"mcpServers": {
"calculator": {
"command": "npx",
"args": [
"mcp-remote",
"http://localhost:8787/mcp" // or remote-mcp-server-authless.your-account.workers.dev/mcp
]
}
}
}
```
Restart Claude and you should see the tools become available.
## Parameter-driven WAPF pricing grids
- \`preview_wapf_pricing_grid\` validates a caller-supplied width/drop base-price matrix, complete fabric surcharge matrices and optional drop-based choice surcharges against one exact draft/hidden WooCommerce product.
- \`apply_wapf_pricing_grid_guarded\` applies only the previewed regular price and WAPF pricing formulas after revalidating product identity, field/choice identities, matrix dimensions, the WAPF hash and deterministic plan hash. It cannot publish and restores both the regular price and field group if verification fails.
- Product IDs, names, metadata IDs, field IDs, choice slugs, axes and all monetary values are runtime parameters; no product-specific pricing is hard-coded.
<!-- Deployment refresh trigger: 2026-09-15T08:05:29.998Z -->
## Staging-to-live product promotion: read-only foundation
The product-promotion integration is split between a narrowly scoped WordPress bridge
and a modular MCP tool registration in `src/tools/product-promotion.ts`.
- `inspect_product_promotion` verifies the authenticated bridge identity, exact
staging/source or live/target role, approved HTTPS origin and absence of write routes
or automatic sync hooks. An optional `product_id` returns the deterministic product
manifest containing identity, publication state, pricing, taxonomy, media integrity
and metadata hashes.
Both tools are read-only. They cannot create, update, publish, delete, upload or
synchronise products.
Live reuses `WC_SITE`, `WP_USERNAME` and `WP_APPLICATION_PASSWORD`. Staging
requires the separate Cloudflare bindings `WC_STAGING_SITE`,
`WP_STAGING_USERNAME` and `WP_STAGING_APPLICATION_PASSWORD`. Site origins and
bridge roles are independently verified before a manifest is accepted.
### Environment-aware WAPF pricing grid
`manage_wapf_pricing_grid` inspects, previews or applies a complete parameter-driven base grid, per-fabric grids and one-dimensional option surcharges on an explicitly selected `live` or `staging` WooCommerce environment. Inspect is read-only and returns compact product, WAPF metadata, field and choice identities. Apply requires the exact preview plan hash and `CONFIRM APPLY WAPF PRICING GRID`, is limited to draft/hidden products, verifies the regular price and complete WAPF field-group hash after the atomic product update, and restores both values if verification fails. The tool contains no product IDs, labels, slugs or prices. An optional `fixed_choice_prices` list can hash-lock and update exact field/choice pricing expressions in the same atomic plan. Each entry verifies the current field label, choice label, slug, pricing type and pricing amount before changing only that choice's pricing type and amount; images, conditions, slugs, labels and unrelated fields remain unchanged.
### Staging Blindmotion plugin deployment
- `manage_staging_blindmotion_plugin_deployment` consolidates inspection and guarded deployment for reviewed Blindmotion plugins on `staging-online.blindmotion.com.au`. The `inspect` action is read-only. The `deploy` action requires exact current-version state, a SHA-256 locked ZIP, the fixed slug/main-file/name identity and `CONFIRM DEPLOY BLINDMOTION PLUGIN`. The WordPress bridge validates the archive, uses a transaction lock, preserves a temporary rollback copy, activates the plugin and verifies the final version and active state. It cannot target live, fetch arbitrary URLs or install unlisted third-party plugins.
This single tool replaces the former Visualizer-only deployment tool without increasing the MCP tool count. The initial allowlist contains the deployment bridge itself, Measurement Guarantee, Motor Selection Guide, Product Promotion Bridge, WAPF Pricing Bridge, Visualizer and the future consolidated Blindmotion CRO Suite.
# Staging work through the deployment bridge
Bridge 1.1.0 adds actions to `manage_staging_blindmotion_plugin_deployment`: `read_source`, `inspect_routing`, `inspect_content`, `preview_content`, `apply_content`. Reads do not schedule or sync contacts. Product edits require the inspected SHA-256 and exact preview-plan SHA-256, permit only description/short_description, and verify read-back with rollback. Use the returned before text with a fresh preview to revert. These operations use the existing dedicated staging credentials and require no browser session. Install the updated bridge before using the new actions. Elementor template editing and routing code mutation remain outside this interface.
Validation: `node scripts/test-staging-work.mjs`. The PR tool ceiling is aligned to the existing 97 tools; these actions add no registered tools.
## Production sample-routing source audit
`get_blindmotion_mcp_source_file({path: "production-sample-routing"})` reads only the current live Code Snippets record 11 using the existing WordPress application-password binding. This additional fixed selector accepts no caller-supplied URL, snippet ID or write arguments, and adds no registered tool. The fixed HTTPS origin, GET method, redirect rejection, 15-second timeout, 256 KiB response cap and `BM_Sample_Routing` class check prevent expanding the operation into arbitrary admin access. It never evaluates PHP, activates snippets, synchronizes contacts or sends email.
The result includes activation status, retrieval time, the SHA-256 of the original source, and a redacted source copy. Credential-related lines, addresses and token-shaped string literals are suppressed. Redactions must be reviewed when comparing classification rules; this tool deliberately returns `production_parity_verified: false` and cannot declare production parity automatically. HTTP and malformed-JSON error bodies are withheld. A WordPress permission or unavailable-route error is reported without changing the server's capabilities or permissions.
Run `node --test scripts/test-production-sample-routing-read.mjs` for the fixed-origin read, identity, redaction, error-body and response-size regression checks. After deployment, use this read together with staging `inspect_routing` to finish PR #47's current-source comparison before any live email changes.
## OAuth connection and explicit Equinox target
The existing `/mcp` URL now requires OAuth for every MCP request. Cloudflare's
`@cloudflare/workers-oauth-provider` owns discovery, dynamic client registration,
PKCE authorization codes, token validation, refresh and revocation. The owner signs
in on the Worker's own consent page with `MCP_OWNER_SECRET`. This is a single-owner
connection with full `business:manage` access, not multi-user account management.
The old static-Bearer `/equinox/mcp` route returns 410 and cannot bypass OAuth.
### Deploy and reconnect in this order
1. Before merging, set the encrypted Worker secret `MCP_OWNER_SECRET` to a NEW
password-manager-generated random value (recommended 64 random characters;
accepted length 32–512). In Cloudflare open this Worker → Settings → Variables
and Secrets → Add → Secret. Keep it in your password manager; do not paste it
into GitHub, chat, URLs, or an MCP tool argument. This is the owner sign-in
password, not a WordPress password and not an OAuth client secret.
2. Deploy. `wrangler.jsonc` declares `OAUTH_KV`; current Wrangler automatically
provisions its KV namespace or reuses the deployed binding. The deploy API
token must have Workers KV Storage edit permission. If it does not, create the
namespace through Cloudflare and bind it as `OAUTH_KV` before deployment.
Do not use a production KV namespace in a preview deployment.
3. Verify unauthenticated POST `/mcp` returns 401 with `WWW-Authenticate` including
`resource_metadata`. Discovery at `/.well-known/oauth-authorization-server`
advertises `/authorize`, `/oauth/token`, and `/oauth/register`.
4. Reconnect the existing ChatGPT custom MCP connection with authentication set
to OAuth and the SAME URL:
`https://remote-mcp-server-authless2.phil-cd4.workers.dev/mcp`.
Leave OAuth client ID/secret blank for dynamic registration when offered.
If the existing connection's authentication mode cannot be edited, recreate
its registration using this URL and OAuth. Enter the owner password only on
this Worker's `/authorize` page after checking the requesting client and
redirect hostname. Approve the connection. No Auth0 account is required.
5. Confirm an authenticated Blindmotion read succeeds before configuring Equinox.
6. Set `EQUINOX_WP_USERNAME` and encrypted `EQUINOX_WP_APPLICATION_PASSWORD` using
an application password created on Equinox. There is NO fallback to the
Blindmotion `WP_USERNAME`, `WP_APPLICATION_PASSWORD` or WooCommerce keys.
Keep the existing `EQUINOX_MCP_TOKEN` (random, 32+ characters) for signing write
previews only; it is no longer an MCP access credential.
7. Call `manage_equinox` with `site: "equinox", action: "discover"`, then
`get_products` with `site: "equinox", limit: 1`. Discovery verifies the REST
site's identity and application-password acceptance before any management.
`get_products.site` accepts `blindmotion` (default for old calls) and `equinox`.
`manage_equinox.site` requires the explicit literal `equinox` and exposes
`discover/read/preview/apply`. Other domain-specific Blindmotion tools remain
Blindmotion-only. No arbitrary URL or global environment switching is accepted.
Equinox credentials are sent only to `https://equinoxwholesaleblinds.com.au`;
redirects are refused. Existing hosting/REST connectivity issues may still need
resolution independently of ChatGPT authentication.
Access tokens expire after one hour and are renewed automatically by the client.
Each successful refresh extends the connection by another 30 days; there is no
fixed monthly sign-in while refreshes continue. A connection with no successful
refresh for 30 days expires and needs owner sign-in again. Revocation, lost client
credentials or client-side connection failures can also require reconnection.
Re-authorizing the same client/resource replaces its old grant. For emergency
revocation delete its grants using the OAuth provider, or clear this dedicated
`OAUTH_KV` namespace to revoke ALL connections. Rotating `MCP_OWNER_SECRET` only
changes future sign-ins; it does not itself revoke issued tokens. Do not roll
back to the old unauthenticated Worker as an authentication recovery procedure.
The literal-name source audit ceiling is 98, including the previously separate
Equinox management tool. That regex audit does not count six dynamically
registered tools; the runtime test verifies the actual 104-tool list has unique
names (103 existing Blindmotion tools plus Equinox management).
`npm run test:mcp-auth` exercises the real Worker in Cloudflare's local runtime.
### Scope
This is a write-enabled management interface, not a read-only connection.
It supports installed REST routes in wp/v2, wc/v3 and Wholesale Suite namespaces:
product/variation CRUD and publication, pricing and REST-visible metadata,
pages/posts, media (including bounded JPEG/PNG/WebP/PDF uploads), customer and
order management, coupons, shipping/tax/payment configuration and REST-visible
WordPress/wholesale settings. Actual rights remain the WordPress user's rights.
Use discover's live route schemas rather than guessing request bodies.
Credential/application-password endpoints and bulk batch endpoints are excluded.
Not every WordPress admin screen exposes REST controls. WAPF/Elementor private
metadata, wholesale role approval/settings, plugin installation, ERP diagnostics,
email marketing and support integrations may need a separate WordPress bridge or
service connector. Discovery reports available routes; unsupported operations fail
explicitly. This patch does not claim to connect unrelated external services.
### Writes and operational limits
Read the resource, preview one explicit operation, then apply the exact operation
with its signed 10-minute preview token and CONFIRM EQUINOX WRITE.
The token binds the site, method, path, query, body/media hash and existing-resource
snapshot where applicable. Modified operations and stale snapshots fail before
writing. No write happens during preview. API-level validation occurs on apply.
HTTP success and read-back data are reported separately; compare returned fields
with intent. A read-back failure after successful mutation is reported without
retrying the write. Previous resource snapshots are returned but rollback is not
automatic. Concurrent writes between validation and mutation are still possible.
WooCommerce writes can invoke normal emails/webhooks/ERP integrations. Connection
authorization is not authorization to send campaigns, charge/refund payments,
grant users access or delete business records. Obtain the relevant task instruction.
Deletion uses the route's normal semantics, including permanent deletion if the
explicit reviewed request uses force=true. Media bytes are limited to 4 MB.
Tokens are not durable single-use receipts; collection creates can be replayed
during token lifetime. Never retry an uncertain create/payment/refund operation:
reconcile the server state first. There is no durable idempotency store in this patch.
Validation during preparation: TypeScript check of the new endpoint against the
installed MCP/Agents/Zod dependencies, plus mocked-runtime tests for fail-closed
authentication, fixed origin, rejected path/routing overrides, no redirects,
non-mutating previews, tampered tokens/operations, stale-resource rejection,
write/read-back, redaction and unsupported routes. Live Equinox connectivity,
installed plugin routes and application-password acceptance remain deployment checks.
This server cannot be deployed
Maintenance
ActivityActive
ResponsivenessNo issues