@W-20598954 MCP Vuepress docs#172
Conversation
|
MCP Server should come before API reference in the header (we can also remove the latter from the homepage, it doesn't need to take up that space). When I talked to Yuming I was wondering if we should try to "merge" the MCP in with the guides docs because there is so much overlap and then have sidebar sections specific to the CLI and MCP. Although maybe the sidebar would grow too large at that point. We should make sure we're referencing back to the Authentication guide for detailed setup guides in AM. |
Done, but I left API ref in the header. Seems useful and isn't crowded on my browser. YMMV.
Done. (sort of). the MCP is partially integrated into the Guide: it shares the same nav menu and quick start includes the MCP.
Done. Linked the various auth references back to the configuration, and from there to the Auth guide. Also removed as much redundancy as I thought reasonable to balance comprehension vs maintainability. I'm sure more could be done here. |
d201b54 to
a0b4d31
Compare
| | Parameter | Type | Required | Default | Description | | ||
| |-----------|------|----------|---------|-------------| | ||
| | `directory` | string | No | Current working directory | Path to directory to search for cartridges. The tool recursively searches for `.project` files to identify cartridges. | | ||
| | `cartridges` | string[] | No | All found cartridges | Array of cartridge names to include in the deployment. Use this to selectively deploy specific cartridges when you have multiple cartridges but only want to update some. | |
There was a problem hiding this comment.
nit: Should we add "If not specified, all cartridges found in the directory are deployed." to be more clear?
|
|
||
| Returns a deployment result object containing: | ||
|
|
||
| - `cartridges` - Array of cartridge names that were deployed |
There was a problem hiding this comment.
cartridges- Array of cartridge mappings that were deployed (each withname,src,dest)
|
|
||
| - `cartridges` - Array of cartridge names that were deployed | ||
| - `codeVersion` - Code version name used for deployment | ||
| - `hostname` - Instance hostname where cartridges were deployed |
There was a problem hiding this comment.
Seems hostname should be removed. Its not included in DeployResult
There was a problem hiding this comment.
nice catch. fixed
| Returns a push result object containing: | ||
|
|
||
| - `bundleId` - Unique identifier for the pushed bundle | ||
| - `project` - MRT project slug |
There was a problem hiding this comment.
Should we update it to match PushResult?
projectSlug- MRT project slugtarget- Target environment (if deployed)
There was a problem hiding this comment.
fixed.
But brings up an interesting aside. Across the b2c tooling repo I think I see inconsistent usage of target, targetSlug, environment, and environmentSlug, not to mention the use of "environment" for process environment variables. Maybe we should standardize on one name for this concept?
There was a problem hiding this comment.
The user facing terms of environment and project should always be used. The slug qualifier should be probably be dropped for ID. I'm ambivalent on whether we say ID or omit it. Consult what managed runtime itself uses in it's UI. Our "ui" (flags, etc) should use the same convention.
Internally, in the SDK, we still make use of the API conventions. Because those are still called project/target in the managed runtime API and will probably always. Logging is also safe to use these terms.
There was a problem hiding this comment.
@clavery not exactly sure what the desired action here is. Currently the SDK returns targetSlug. If the user facing term is environment then maybe the SDK needs a consistent mapping utility to change the SDK names to user names? I could see the exact same code needed for CLI as MCP for PushResult, for example.
|
|
||
| | Parameter | Type | Required | Default | Description | | ||
| |-----------|------|----------|---------|-------------| | ||
| | `directory` | string | No | Current working directory | Path to directory to search for cartridges. The tool recursively searches for `.project` files to identify cartridges. | |
There was a problem hiding this comment.
Can we update the 'Current working directory' to something like:
Working directory from --working-directory flag or SFCC_WORKING_DIRECTORY env var (falls back to process.cwd())
There was a problem hiding this comment.
ok. done.
| Projects with multiple markers (e.g., cartridges + PWA Kit) get combined toolsets. For example: | ||
| - Cartridges + PWA Kit → CARTRIDGES, PWAV3, MRT, SCAPI | ||
|
|
||
| ## Testing the MCP Server Locally |
There was a problem hiding this comment.
Wonder should we remove this testing locally section? I feel this doc is for the end user but not for contributors who should reference contributor.md or mcp readme.md for local setup.
There was a problem hiding this comment.
Moved all the development setup and guideles to a new MCP focused md file in the source package.
|
Lets get a changeset for the docs and the MCP and use this is as the starting point for MCP release changes |
c10c86e to
1d62eb6
Compare
Done as a minor bump to dx-docs only. Please review. |
| @@ -1,12 +1,15 @@ | |||
| --- | |||
| description: Introduction to the B2C CLI and SDK for Salesforce Commerce Cloud B2C code deployment, site management, and sandbox operations. | |||
| description: Introduction to the B2C CLI, MCP Server, and SDK for Salesforce Commerce Cloud B2C code deployment, site management, and sandbox operations. | |||
There was a problem hiding this comment.
Just noticed, should 'Salesforce Commerce Cloud B2C' be changed to 'Salesforce B2C Commerce'? Same for https://github.com/SalesforceCommerceCloud/b2c-developer-tooling/pull/172/changes#diff-a9f09e5fd39208124b216a0cac772b60ab660bf177b9ecd1ab87f18006cecdbcR7
| "description": "Salesforce B2C Commerce Command Line Tools", | ||
| "version": "0.0.1-preview", |
There was a problem hiding this comment.
Was trying to apply some consistency of attribute ordering across package.json and arbitrarily chose description then version, but happy to use ither order or revert the order change.
| default: 'true' | ||
| working-directory: | ||
| description: 'Working directory for the command' | ||
| project-directory: |
bfd07a1
Summary
Add MCP to Documentation site.
workingDirectoryvariable names asprojectDirectoryeverywhere (follow up to feat: rename --working-directory to --project-directory #199).Testing
Pull PR and test doc site locally with
pnpm run docs:devDependencies
3pl-approvedis set by a maintainerpnpm test)pnpm run format)