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:

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:

npm create cloudflare@latest -- my-mcp-server --template=cloudflare/ai/demos/remote-mcp-authless

Related MCP server: cimb-mekari-mcp-server

Customizing your MCP Server

To add your own tools to the MCP server, register each tool on the McpServer created in the createServer() function in src/index.ts using server.registerTool(...).

Guarded Vimeo website-video intake

The existing Blindmotion Media Intake app now supports either Vimeo website video or Meta advertising creative. Vimeo is the default destination. It sends the chosen MP4/MOV directly through a single-use Worker permit, creates an embed-only, non-downloadable Vimeo video, verifies the TUS byte offset and reads the new video back before returning its ID and embed URL. The Vimeo token never reaches the browser. Exact existing titles are reused; ambiguous duplicates are refused.

manage_vimeo_video provides connection status, exact video inspection and guarded upload permits without adding separate one-off tools. The retired duplicate open_blindmotion_media_intake_v7 registration keeps the source tool ceiling at 102; open_blindmotion_media_intake is the stable app entry point.

Configure the encrypted Cloudflare secret VIMEO_ACCESS_TOKEN with an authenticated Vimeo token carrying private, upload and edit scopes. An optional VIMEO_FOLDER_URI Worker variable places new videos in one fixed Vimeo folder. See Vimeo website-video intake for setup, safeguards and verification.

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.

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.

To connect to your MCP server from Claude Desktop, follow Anthropic's Quickstart and within Claude Desktop go to Settings > Developer > Edit Config.

Update with this configuration:

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

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.

Staging roller maintenance without browser login

The existing manage_staging_blindmotion_plugin_deployment tool accepts action: "roller_maintenance" and a nested request. No registered tool is added. Requests use action: inspect | preview | apply, resource: wapf | snippet, an exact id and expected_name. Only the fixed staging origin is addressable, through the existing WP_STAGING_USERNAME and application password.

WAPF maintenance updates existing field labels, required flags, conditionals, pricing or options. Field IDs and ordered choice slugs cannot change. Snippet maintenance replaces uniquely matching source fragments in existing roller/width/measurement/sample snippets, preserving activation and scope. It cannot create/delete snippets. Review and syntax-check PHP before applying; an active snippet edit can affect staging immediately.

Inspect returns a current-state SHA-256 and original backup. Preview takes that digest and changes (field_updates with field_id, property, value_json, or replacements with find, replace), returning an exact plan digest and proposed state. Apply repeats these inputs with plan_sha256 and confirmation: "CONFIRM APPLY STAGING ROLLER MAINTENANCE". Preserve preview backups in the task record before applying. The tool re-reads immediately before writing, verifies afterward and attempts rollback only when the observed state still matches the known proposed state. Unknown outcomes or concurrent edits stop explicitly; there is no server-side transactional lock and rollback is not guaranteed during outages.

Deployment checks: existing staging deployment bridge 1.1.27 was confirmed active on 17 October 2026. That uses dedicated deployment credentials; it does NOT establish that the separate staging WordPress credential can edit Code Snippets. After deployment, inspect the exact WAPF product and snippet first. HTTP 401/403 or a missing snippet REST route requires permission/route repair; do not silently fall back to another browser login. No WordPress plugin upgrade is introduced by this patch. A connector schema refresh may be needed. OAuth expiry/revocation and cloud-browser takeover remain independent of these server changes. Production changes and browser/cart behaviour are not verified by a successful API write.

Validation: TypeScript passes; lint has no errors; the configured 100-tool source ceiling passes unchanged. Mocked execution checks cover non-writing inspect/preview, current-state and plan guards, preserved choices/publication/activation, concurrent-edit refusal, staging-only addressing, and exact snippet replacements. Existing staging-work tests pass. Server permissions, real writes, cart quantity totals and 2400-to-2396 width behaviour remain post-deployment checks. Release follows the existing externally reviewed merge and Cloudflare workflow.

Meta account spending limit

get_meta_budget_settings preserves its existing status/limit budget reads. Its optional account_spend_limit object adds read, preview, apply, preview_reset and apply_reset modes without increasing the 100-tool surface. It targets only the configured AUD Meta ad account; it reuses the existing Meta token and API version. Account-level read and write access must be granted to that system user by Meta. No new secrets are required. Deployment itself never changes a spending limit.

Read:

{"account_spend_limit":{"mode":"read"}}

Returns current finite limit (or explicit unlimited/unknown state), spend counted against the cap, remaining allowance, account status/disable reason and timezone. Missing monetary fields remain unknown. Minor units from the account API are converted to AUD; Insights spend is already in AUD. Forecast uses the last seven complete days in the returned account timezone, not UTC or the caller's timezone. Warnings trigger when remaining allowance is at or below the largest of A$500, 20% of the finite limit, or three days of average recent spend. An exhausted cap is explicit. The estimate can understate future spending after a delivery outage. Meta-imposed daily restrictions and payment failures are separate from this cap.

Preview:

{"account_spend_limit":{"mode":"preview","expected_account_name":"<exact name from read>","new_limit_aud":5000}}

Shows before/after cap and allowance, plus a signed 15-minute token. Present the exact account, proposed finite cap and potential resumption of active campaign spending to the user and obtain approval before applying. Apply repeats those exact inputs with mode: "apply", preview_token, and confirmation: "CONFIRM META ACCOUNT SPEND LIMIT CHANGE". A generic instruction to install this capability does not approve any financial change.

Apply rejects tampered/expired tokens, changed identity/currency/timezone/status, changed current cap and a decreased spent counter. Normal growth in spent is allowed, with the requested cap rechecked against current spend. Only a positive finite cap above counted spend can be set (whole cents, up to A$1 million). Cap changes post only spend_cap; resets use the separate flow below. Neither flow removes the limit or changes campaign budgets or statuses. The account is reread afterward and the actual cap verified. If an API write or verification is uncertain, the result explicitly instructs a read before any retry; no automatic retry or rollback occurs. Repeating an approved request when the cap is already at its target is a verified no-op.

Reset amount spent

For a finite cap with positive counted spend, call preview_reset with the exact account name. The preview shows the unchanged cap, existing counted spend, proposed zero counter and restored allowance. Approve this exact reset and its potential to resume active campaign spending, then call apply_reset with the account name, preview token and confirmation: "CONFIRM META AMOUNT SPENT RESET". No new limit is supplied. The distinct signed reset token expires after 15 minutes and binds all observed account state, including exact counted spend. Any state change requires a fresh preview. Apply sends only spend_cap_action=reset. It verifies counted spend is zero and the cap remains unchanged. Historical reporting and charges are not erased. If spend has already accrued or the response is uncertain, report UNVERIFIED/UNKNOWN and reread; never retry automatically. A successful reset makes the account ineligible for another reset while counted spend is zero. Live reset permission and behavior remain unverified until an authorized reset.

Early-warning delivery

The read tool computes warnings; it does not run a background timer or send mail. After deployment, a daily read-only scheduled check should call the read mode and notify Phil for APPROACHING_LIMIT or EXHAUSTED, showing allowance and estimated runway. UNKNOWN requires investigation, never a healthy assertion. That check must not preview/apply financial changes automatically. The existing weekly marketing review can include the same read. No proactive alert schedule is installed by this source change.

Tests: node --test scripts/test-meta-spend-limit.mjs. The suite covers AUD units, local dates, missing data, warnings, approval/token integrity, state drift, verification and uncertain-write handling. Live account access remains a post-deployment read-only check; never test a write without a separately approved amount.

API references: Meta AdAccount reference, Meta's account update example, Meta account spending-limit help.

Read-only Google Ads budget constraint diagnostics

get_google_ads_campaign_performance retains existing reporting. Optionally pass budget_diagnostics: { campaign_id, expected_campaign_name } with the existing start_date and end_date (inclusive, maximum 93 days). No new exposed tool is added and the existing shared-budget mutation refusal remains unchanged.

The diagnostic resolves the configured Google customer, AUD currency and account timezone, validates the exact campaign name/ID/resource, and reads its budget's identity, amount, period, sharing flag and reference count. It returns current budget members (including paused/removed members), each member's period spend, combined spend by day (including zero-delivery days), and indicative utilisation of the current daily budget. It does not infer historical budget amounts or membership changes. Reports cover the supplied dates in Google's account timezone.

Current campaign primary status/reasons, bidding strategy and target ROAS are shown separately from historical Search impression share and losses due to budget or rank. Google may omit these metrics or not support them for a campaign: null means unavailable, never zero. An explicitly reported BUDGET_CONSTRAINED reason is positive current evidence. Its absence alone is not proof of no constraint. Historical positive budget-loss share is evidence for that reporting period only. Google may return bounded/estimated shares; these remain unaltered fractions.

Current-budget utilisation is contextual, not proof of a budget constraint. Google can overdeliver on individual days; underspending can also reflect bid/target, demand, eligibility or other restrictions. A budget change affects all sharing campaigns. This feature executes only fixed SELECT queries through the existing configured-account reader, and cannot mutate or validate a proposed budget change. If impression-share reads fail, budget/spend results survive with an explicit warning. Invalid identity, dates, financial rows or potentially truncated group results fail closed rather than presenting complete-looking totals.

Tests: node --experimental-strip-types --test scripts/test-google-budget-diagnostics.mjs. They cover shared spend, micros, zero days, missing vs zero impression shares, partial-query failure, absence of current budget evidence, non-daily budgets, injection/date validation, customer/campaign identity and truncation safeguards. Both PR and deployment workflows run the tests. Live Google field availability and real account results must be verified after deployment.

References: Google v25 campaign fields and campaign budget fields.

Exact Google daily budget controls (including shared budgets)

The existing preview_google_ads_campaign_changes and apply_google_ads_campaign_changes_guarded tools accept SET_DAILY_BUDGET_AUD. It supports both increases and decreases for individual and shared DAILY budgets, without percentage rounding or multiple compounded increases. No new exposed tools are added.

Read get_google_ads_campaign_performance with budget_diagnostics first to obtain the budget identity, current amount and every member campaign. Then preview:

{
  "changes": [{
    "action": "SET_DAILY_BUDGET_AUD",
    "budget_id": "<budget ID from diagnostic>",
    "expected_budget_name": "<exact budget name>",
    "expected_current_daily_budget_aud": 22,
    "new_daily_budget_aud": 32,
    "expected_member_campaigns": [
      { "campaign_id": "<member ID>", "expected_campaign_name": "<exact member name>" }
    ]
  }]
}

The member list must contain every attached campaign, including paused and removed members returned by the diagnostic. The preview shows their statuses and the exact old/new amount. Shared-budget approval applies to the whole group. The configured customer must match and use AUD; the budget must be ENABLED and DAILY. Positive amounts must use whole cents, up to A$500/day. There is no percentage cap on this exact-amount path; the legacy percentage action retains its 25% ceiling and refusal of shared budgets.

Apply the same request with the returned expected_plan_sha256 and confirmation: "CONFIRM APPLY GOOGLE ADS CAMPAIGN CHANGES" only after the exact change is approved. The hash covers budget identity, current amount, currency, timezone, sharing and complete member IDs/names/statuses. Row ordering is normalised. Drift invalidates the preview. Each budget appears once per plan; overlapping campaign controls are refused. Google validation runs before writing, then exact-budget state is rechecked immediately before the atomic Google mutation. Only campaignBudget.amount_micros is changed. Post-write verification checks both amount and membership. Recovery attempts the exact original amount only if the approved post-write state still matches, avoiding overwriting a concurrent edit. A transport error can leave write outcome uncertain: re-read before retrying.

Cross-platform reallocations are not atomic: Google and Meta have separate APIs. Verify both previews before changing either side, report partial completion explicitly and re-read both amounts after completion. This feature does not automatically reduce Meta budgets, change ROAS targets or apply a reallocation.

Tests exercise the real registered preview/apply callbacks, shared $22→$32, decreases and individual budgets, no-op, cents, ownership/currency, complete membership, stale hashes, duplicate plans, API validation failure, verification and guarded rollback. Both PR and deployment workflows run: node --experimental-strip-types --test scripts/test-google-budget-controls.mjs. Live Google validation and verification remain required after deployment.

Read-only Facebook and Instagram comment setup

get_meta_lead_campaign_assets now accepts an optional comment_request for Page inventory/permission diagnostics, Facebook posts/comments/replies, linked professional Instagram media/comments/replies and candidate ad-comment sources. Original calls are unchanged; the 101-tool source ceiling is preserved. This stage is read-and-draft only: no publishing, moderation, new permissions or monitoring schedule. See the usage, coverage limits and live acceptance checklist. Run npm run test:meta-comments for fixture and Cloudflare-runtime checks.

Meta daily budget updates

update_meta_daily_budget allows an explicitly confirmed campaign or ad-set daily budget increase of up to 50% per change, with an A$500/day maximum. Account ownership checks and the existing confirmation phrase remain required. Decreases remain supported. From A$24/day, the largest permitted single increase is A$36/day; a direct change to A$45/day remains outside this limit. Google budget limits are unchanged. The existing Meta test suite also runs daily-budget boundary tests.

iDempiere direct database audit

The authenticated read_idempiere_database tool provides bounded, read-only production/scanning queries. It remains disabled until a dedicated database role, verified TLS connection and explicit tenant/organisation scope are configured. See setup and verification. It cannot execute arbitrary SQL or update ERP records.