Loading ToolBench
Commerce Cloud MCP Server for Salesforce Commerce Cloud OCAPI integration
This server has 24 tools with a mix of quality issues. All tools have basic descriptions and schemas are present with type definitions, but there are significant structural and documentation problems. Schema quality varies: search tools use a generic 'searchSchema' that is referenced but not fully inspected in the provided code, parameter descriptions are minimal (typically under 20 chars), and many parameters lack actionable guidance. The server exhibits common community server gaps: generic parameter names ('options'), no documented return schemas, missing output field documentation, and no error handling patterns. Most tools follow verb_noun naming (get_*, search_*, update_*) which is positive. However, descriptions are often boilerplate and do not explain WHEN to use each tool vs similar alternatives (e.g., get-product-by-id vs product-search). The codebase shows tool registration via `server.tool()` but the schema objects are imported from `./schema` which was not provided; this makes full schema validation impossible, capping per-tool scores accordingly.
Searches for categories using the SFCC OCAI - Data API This requires the search query to be provided as an input Additional options can be provided to filter the search results
Searches for contents using the SFCC OCAI - Shop API This requires the search query to be provided as an input Additional options need to be provided to filter the search results
Creates a custom object by its type and key using the SFCC OCAI - Data API This requires the object type and key to be provided as an input The object to create needs to be provided as an input
Searches for custom objects using the SFCC OCAI - Data API This requires the object type and search query to be provided as an input Additional options can be provided to filter the search results
Fetches a basket by their id using the SFCC OCAI - Shop API This requires the basket id to be provided as an input
Generic parameter 'options' used across 13 tools (get-product-by-id, get-products-by-ids, content-search, etc.). Lacks type specificity and makes it impossible for LLMs to understand what options are valid without trial and error.
Output schemas not documented. No tool specifies what fields are returned, forcing LLMs to guess at response structure and preventing safe downstream tool chaining. E.g., does product-search return product_id, id, or productId?
Descriptions are boilerplate and do not explain when to use each tool vs similar alternatives. E.g., product-search and get-product-by-id both retrieve products but descriptions do not explain the distinction (search vs exact lookup).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 47 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
Fetches a list of categories by their ids using the SFCC OCAI - Shop API This requires the category ids to be provided as an input
Fetches a category by their id using the SFCC OCAI - Shop API This requires the category id to be provided as an input
Fetches a content by its id using the SFCC OCAI - Data API This requires the content id to be provided as an input
Fetches multiple contents by their ids using the SFCC OCAI - Shop API This requires the content ids to be provided as an input
Fetches a custom object by its type and key using the SFCC OCAI - Data API This requires the object type and key to be provided as an input
Fetches a customers basket by their customer id using the SFCC OCAI - Shop API This requires the customer id to be provided as an input
Fetches a customer by their customer number using the SFCC OCAI - Data API This requires the customer number to be provided as an input
Fetches a customer by their customer id using the SFCC OCAI - Shop API This requires the customer id to be provided as an input
Fetches a customer list using the list id from the SFCC OCAI - Data API This requires the list id to be provided as an input and the list id is always set to the site id
Fetches a customers order by their customer id using the SFCC OCAI - Shop API This requires the customer id to be provided as an input
Fetches an order by its id using the SFCC OCAI - Shop API This requires the order id to be provided as an input
Get a product by ID using the SFCC OCAI - Shop API
Get multiple products by their IDs using the SFCC OCAI - Shop API
Fetches a list of job executions using the SFCC OCAI - Data API This requires the search options to be provided as an input
Searches for orders using the SFCC OCAI - Shop API This requires the search query to be provided as an input Additional options need to be provided to filter the search results Use order-search-usage resource to use the queries filed in the options
Searches for products using the SFCC OCAI - Data API This requires the search query to be provided as an input Additional options can be provided to filter the search results
Updates a content by its id using the SFCC OCAI - Data API This requires the content id and library id to be provided as an input The content to update needs to be provided as an input
Updates a custom object by its type and key using the SFCC OCAI - Data API This requires the object type and key to be provided as an input The object to update needs to be provided as an input
Updates a product by its id using the SFCC OCAI - Data API This requires the product id to be provided as an input The product to update needs to be provided as an input
Parameter descriptions are minimal. Examples: 'The expand parameter. A comma separated list...' is incomplete, unclear what values are valid. 'The field to query documents' for 'query' param is vague and does not explain expected format (is it a string, object with field:value pairs?).
Search tools reference 'db_start_record_' parameter alongside 'start' parameter for pagination, unclear which is correct or how they differ. This forces trial-and-error and increases API call waste.
No error handling guidance. Tools do not specify what errors are possible (e.g., 'not found', 'unauthorized', 'rate limited') or how to recover. Error responses would be opaque to LLMs.
WRITE tools (update-product-by-id, update-custom-object, create-custom-object, update-content-by-id) lack idempotency guarantees or confirmation steps. Agents could accidentally duplicate records or overwrite data on retry.
Search tools accept 'count' parameter but no documented limit or default. Unbounded counts could cause memory/timeout issues. Baseline: production tools typically cap lists at 20-50.
Tool names use hyphens (get-product-by-id) but no consistency check if downstream APIs expect underscores or camelCase. If response uses product_id but next tool expects productId, chaining fails silently.
No indication whether tools support filtering by human-readable names vs system IDs only. E.g., get-customer-by-id, does it accept customer_number as well, or only internal ID?