refactor(cloudflare): rename MCP provider service

[LJAYi]

Summary

• rename the official MCP-backed provider service from cloudflare_mcp to cloudflare
• expose the shorter model-facing Action IDs cloudflare.docs, cloudflare.search, and cloudflare.execute
• rename the Provider display name and source directory while retaining the official MCP implementation details
• migrate persisted connections, OAuth client config keys and pending states, run history, runtime-token rules, and stored runtime policy rules
• treat the OAuth config row key as the authoritative service ID so encrypted legacy payloads remain usable without decrypting them in SQL

Motivation

The cloudflare_mcp service name makes models interpret the Actions as the separately connected Cloudflare MCP server and prefer that tool surface instead of the Cloudflare Provider exposed through Open Connector. The shorter cloudflare namespace makes the Open Connector Actions unambiguous in model-facing catalogs.

Compatibility

Stored runtime data is migrated from cloudflare_mcp to cloudflare. Deployment-level policy environment variables are outside runtime storage and operators using explicit cloudflare_mcp.* or cloudflare_mcp rules will need to rename those entries.

Validation

• npm run generate:catalog
• npm run fix-check
• npm test — 69 files, 724 tests passed
• focused SQLite/D1 storage tests — 34 tests passed

[coderabbitai]

Summary by CodeRabbit

• Improvements
  • Standardized the Cloudflare service name across connections, authentication settings, runs, tokens, policies, and actions.
  • Existing Cloudflare configurations and activity records are automatically migrated to the updated naming.
  • Cloudflare authentication configurations now consistently retain their saved service information.
• Tests
  • Added coverage validating migration of existing Cloudflare data and updated runtime storage behavior.

Walkthrough

The Cloudflare provider identifier changes from cloudflare_mcp to cloudflare. Provider actions, display metadata, executors, and follow-up action IDs use cloudflare. Migration 0011_cloudflare_service.sql updates existing connections, OAuth data, run logs, runtime tokens, and runtime policies. D1 and SQLite OAuth stores restore the persisted service value. Tests cover migration ordering, D1 setup, and legacy data conversion.

Sequence Diagram(s)

sequenceDiagram
  participant Provider
  participant RuntimeStore
  participant SQLite
  Provider->>RuntimeStore: Use cloudflare service identifier
  RuntimeStore->>SQLite: Read or migrate persisted records
  SQLite-->>RuntimeStore: Return cloudflare service data
  RuntimeStore-->>Provider: Return normalized configuration

Loading

Possibly related PRs

• oomol-lab/open-connector#232: Introduces the Cloudflare MCP provider actions and service identifiers updated by this pull request.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title follows the required format and clearly describes renaming the Cloudflare MCP provider service.
Description check	✅ Passed	The description explains the service rename, persisted-data migration, compatibility impact, and validation results.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

✨ Finishing Touches

✨ Simplify code

• Create PR with simplified code

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[coderabbitai]

🧹 Nitpick comments (2)

src/server/storage/sqlite-runtime-store.test.ts (1)

580-604: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Share the migration list and the runtime_migrations DDL.

This test repeats the migration names already listed at line 52, and it recreates the runtime_migrations schema that runSqliteMigrations owns. Both copies drift when a migration is added or the bookkeeping table changes. Extract a module-level constant for the ordered migration names, and derive the legacy list by slicing it. Reuse a single helper for the bookkeeping table DDL.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/server/storage/sqlite-runtime-store.test.ts` around lines 580 - 604,
Extract the ordered migration names into a module-level constant and reuse it
throughout the test, deriving the legacy migration list via slicing instead of
duplicating names. Extract the runtime_migrations table definition into a shared
helper and use that helper in the test setup and runSqliteMigrations-related
setup, so the bookkeeping schema has one source of truth.

src/server/storage/d1-runtime-store.test.ts (1)

454-478: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Read the migrations directory instead of listing each file.

Every new migration requires another exec block here. Enumerate migrations/ and apply the files in sorted name order. The test database then stays current automatically.

♻️ Proposed refactor

 constructor() {
-    this.database.exec(readFileSync(new URL("../../../migrations/0001_runtime.sql", import.meta.url), "utf8"));
-    // ... one block per migration ...
-    this.database.exec(
-      readFileSync(new URL("../../../migrations/0011_cloudflare_service.sql", import.meta.url), "utf8"),
-    );
+    const migrationsDir = new URL("../../../migrations/", import.meta.url);
+    for (const name of readdirSync(migrationsDir).filter((file) => file.endsWith(".sql")).sort()) {
+      this.database.exec(readFileSync(new URL(name, migrationsDir), "utf8"));
+    }
 }

Add readdirSync to the existing node:fs import.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/server/storage/d1-runtime-store.test.ts` around lines 454 - 478, Update
the test database constructor to enumerate the migrations directory with
readdirSync, sort migration filenames by name, and execute each file in order
using the existing database.exec flow. Replace the hardcoded migration list
while preserving the current migration URL resolution and file-reading behavior.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@src/server/storage/d1-runtime-store.test.ts`:
- Around line 454-478: Update the test database constructor to enumerate the
migrations directory with readdirSync, sort migration filenames by name, and
execute each file in order using the existing database.exec flow. Replace the
hardcoded migration list while preserving the current migration URL resolution
and file-reading behavior.

In `@src/server/storage/sqlite-runtime-store.test.ts`:
- Around line 580-604: Extract the ordered migration names into a module-level
constant and reuse it throughout the test, deriving the legacy migration list
via slicing instead of duplicating names. Extract the runtime_migrations table
definition into a shared helper and use that helper in the test setup and
runSqliteMigrations-related setup, so the bookkeeping schema has one source of
truth.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f1bb0c2a-d3f9-4533-8aae-2ce120518b06

📥 Commits

Reviewing files that changed from the base of the PR and between b79ae14 and 48c22e5.

📒 Files selected for processing (8)

• migrations/0011_cloudflare_service.sql
• src/providers/cloudflare/actions.ts
• src/providers/cloudflare/definition.ts
• src/providers/cloudflare/executors.ts
• src/server/storage/d1-runtime-store.test.ts
• src/server/storage/d1-runtime-store.ts
• src/server/storage/sqlite-runtime-store.test.ts
• src/server/storage/sqlite-runtime-store.ts

[l1shen]

I do not think this rename is justified as currently described.

All existing Cloudflare providers use qualified IDs (cloudflare_dns, cloudflare_r2, cloudflare_worker, etc.), so the unqualified cloudflare namespace implies that this is the canonical or umbrella Cloudflare integration. It is not: this provider exposes a separate docs / search / execute Code Mode surface and does not aggregate or replace the typed providers. In that context, mcp is a meaningful public differentiator, not only an executor implementation detail.

The claimed model confusion is also not supported by a reproduction or evaluation, while the rename changes public Action IDs and other external references. Unless the explicit product decision is to make this the default Cloudflare provider, I think it should retain a qualified service ID.

I do not support the rename in its current form.

[LJAYi]

Thanks for raising the namespace concern. One relevant detail may not have been clear in the PR description: Cloudflare describes this unified MCP server as “a token-efficient MCP server for the entire Cloudflare API,” covering around 2,500 endpoints. Its documented supported products include Workers, R2, DNS, KV, D1, Pages, Firewall, Access, and others.

So while this provider does not aggregate the typed Action definitions from cloudflare_dns, cloudflare_r2, or cloudflare_worker, its search / execute surface can operate across those same products and can serve as a general-purpose Cloudflare API integration, subject to the token’s permissions.

I agree that this distinction between capability coverage and typed Action aggregation should be made explicit. Does that broader API scope change your view on the cloudflare service ID, or would you still prefer a qualified ID for architectural consistency?

[l1shen]

Thanks for clarifying the API coverage. That confirms this provider has broad capabilities, but it does not resolve my naming concern.

The unqualified cloudflare ID would position this as the default or preferred Cloudflare integration. That is not the current direction of this project: we prefer typed providers over the MCP-style docs / search / execute surface.

Broad API coverage does not by itself make this the canonical provider. In this case, mcp is a meaningful public distinction because it identifies a different, non-preferred interaction model, rather than merely an internal implementation detail.

I therefore still do not support changing the public service ID to cloudflare. Please keep a qualified service ID, or explicitly document a product decision to make this surface the default before changing it. The model-confusion claim would also benefit from a reproduction or evaluation.