feat(mcp): implement MRT Push MCP Tool

[patricksullivansf]

Summary

Provides an implementation for the MCP MRT Bundle Push Tool (mrt_bundle_push).

• implement using MRT SDK pushBundle
• add support for alternate cloud origins via SFCC_MRT_CLOUD_ORIGIN, --cloud-orgin, and mrtOrigin options. Update adapter tests for cloud origin.
• add unit tests for MCP MRT Bundle Push Tool, and introduce dependency injection pattern for SDK stubbing.
• copy test file lint rule exceptions from CLI project to reduce spurious warnings.
• remove trailing whitespace in unrelated storefrontnext/README.md

Testing

This was tested in cursor within a folder created with the commands:

npx @salesforce/pwa-kit-create-app
cd retail-react-app
npm run build

To run the MCP we used the mcp.json below with the prompt run the bundle push tool with message 'from mcp'

    "b2c-dx": {
      "command": "node",
      "args": [
        "/opt/workspace/dev/b2c-developer-tooling/packages/b2c-dx-mcp/bin/dev.js",
        "--working-directory",
        "${workspaceFolder}",
        "--toolsets",
        "MRT",
        "--cloud-origin",
        "https://cloud-staging.mrt-staging.com",
        "--project",
        "cc-sparks",
        "--allow-non-ga-tools",
        "--debug"
      ],
      "env": {
        "SFCC_MRT_API_KEY": "REDACTED"
      }
    }

Note the inclusion of local MCP server path, explicit destination & credentials (see caveats below)

The bundle successfully uploaded and can be seen ready to be deployed in https://runtime-admin-staging.mobify-storefront.com/salesforce-internal/cc-sparks/patrick

However, there are caveats worth further investigation

• the current folder used in cursor seems off.  It always starts with ./build but gives a file not found error, then retries with absolute path to build folder and succeeds.
• setting options in package.json seem to be ignored. For example, "b2c": { "mrtProject": "cc-sparks" }.
• it fails to load and use the api_key from my ~./mobify file. For example, { "username": "patricksullivan@salesforce.com", "api_key": "REDACTED" }

---

• Tests pass (pnpm test)
• Code is formatted (pnpm run format)

[clavery]

setting options in project.json

Do you mean package.json? or dw.json?

[clavery]

it fails to load and use the api_key from my ~./mobify file

Highly recommend using mcp inspector tool here and running the MCP with --log-level trace to see what's going on. It's possible the config loading logic in the MCP is not correct.

[patricksullivansf]

setting options in project.json

Do you mean package.json? or dw.json?

Oops, corrected description. I mean package.json of the test project (retail-react-app)

[yhsieh1]

I do not get chance to test it but it looks good.

[yhsieh1]

is this the correct sequence to get origin? do we still have issue read from dw.json?

[patricksullivansf]

The actual sequence is apparently this, but I'm not sure we need his level of detail?

 /** MRT API origin URL from --cloud-origin flag (oclif also checks SFCC_MRT_CLOUD_ORIGIN env var), mrtOrigin in dw.json, or default */

[clavery]

The MCP shouldn't be concerned with reading from dw.json or ~/.mobify ever. It is only concerned with flags and env vars (which are tied to the flags anyway in oclif so just flags). Those are passed into the config resolution logic if we have it and you get origin: this.resolvedConfig.values.mrtOrigin. But this should generally be concerned with the SDK operations not the MCP.

We do have an annoying issue were it's called mrtOrigin and cloudOrigin interchangably. But since this isn't a customer need it's not a huge deal

[clavery]

Also the MRT operations in the SDK are inconsistent in signature patterns (some take a client some create it internally). We identified this in another PR. I'll probably do a refactoring pass on those at some point.

[yhsieh1]

Thank you for adding it.

[clavery]

happy to look deeper in main. approving to unblock other things