Salesforce Commerce Cloud Agentic MCP

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each tool targets a distinct entity or operation with no overlap. Tools like sf_search_products and sf_products_by_family provide different views (search vs. category), and sf_list_pricebooks vs. sf_pricebook_entries clearly separate listing price books from viewing their entries.
Naming Consistency4/5
All tool names begin with 'sf_' and use lowercase with underscores, but the pattern varies: some use verb_noun (sf_list_pricebooks), others use noun_preposition_noun (sf_orders_by_status), and one is a noun phrase (sf_order_items). Despite minor inconsistency, the style is uniform and readable.
Tool Count5/5
8 tools is well-scoped for a Salesforce Commerce Cloud server covering price books, orders, and products. Each tool serves a clear purpose without overloading the agent.
Completeness3/5
The tool set covers reading and searching for orders, products, and price books, and includes one update (product). However, it lacks create/delete operations for orders and products, and no tools to manage price book entries or orders beyond reading, leaving notable gaps in the lifecycle.
Average 4.1/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 2 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds context beyond the destructiveHint annotation by stating 'Only specified fields change' and giving examples of common operations. It reinforces the destructive nature and provides insight into partial update semantics, though it omits details on permissions or side effects.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is somewhat redundant, repeating the update purpose in two paragraphs and including extraneous tags like [INSTRUCTIONS] and [DESTRUCTIVE]. While informative, it could be more concise by merging the two parts and removing redundant elements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 5 parameters and no output schema, the description adequately covers the purpose, common use cases, and partial update behavior. It does not cover error conditions or required permissions, but these are not critical given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 100% schema description coverage, the schema already documents parameters. The description adds value by providing real-world examples (e.g., set IsActive to false to discontinue, change Family to reclassify) and emphasizing partial updates, which deepens understanding beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose4/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it patches a Product2 sObject and lists common operations like setting IsActive to false or changing Family. It distinguishes from sibling tools like sf_search_products by emphasizing the update action, though it could explicitly differentiate from other update tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines3/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when updating product fields but does not explicitly state when not to use it or provide alternatives. Sibling tools suggest context, but no direct guidance is given for choosing this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's '[READ-ONLY]' tag adds no new safety info. The description does mention the tool uses SOSL and returns specific fields, but it does not disclose potential side effects, rate limits, or permission requirements. This is acceptable given the annotations cover the safety profile.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise overall, with two paragraphs and key information front-loaded. The '[INSTRUCTIONS]' tag is unnecessary and adds noise, but it does not significantly detract from clarity. Every other sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a search tool with no output schema, the description adequately explains return fields (name, code, family, description, active status) and usage context (product catalog, price book linkage). It could be slightly improved by mentioning pagination or ordering, but it is complete enough for an AI agent to understand and invoke the tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with both parameters described ('Product name or product code' for query, 'Maximum results (default: 20)' for limit). The description adds no additional semantic meaning beyond what the schema already provides, which is adequate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool queries Product2 sObjects via SOSL and returns specific fields (name, code, family, description, active status). It distinguishes itself from sibling tools like sf_products_by_family (filter by family) and sf_update_product (update), providing a specific verb and resource.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear usage context: 'Use when the user asks about product catalog, wants to find a specific product, or needs product IDs for orders.' It explains how products relate to price books. However, it does not explicitly state when not to use this tool versus alternatives, which would improve guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. The description adds that the tool is [READ-ONLY] and specifies sorting by total amount descending, which provides behavioral context beyond the annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is relatively concise and front-loaded with the core action. Minor formatting issues (bracketed instruction) but overall efficient with no wasted sentences.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a filtered list tool with well-documented parameters, the description provides enough context through examples and sorting behavior. No output schema exists, but the return values are implied by the description.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with clear descriptions for both parameters (status: Draft/Activated, limit: default 20). The description reinforces these values but does not add significant new meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it filters Order records by status and sorts by total amount descending, with specific use cases like 'how many draft orders need activation?' and 'show all activated orders'. This distinguishes it from sibling tools like sf_search_orders, which likely provides broader search capabilities.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit context for when to use (e.g., order management, revenue analysis) with example queries. Does not mention when not to use or alternatives, but the examples make the intended usage clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description reinforces this with '[READ-ONLY]' and adds context about the data model (price book entries define prices in specific contexts). No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is mostly concise but has slight repetition: the first sentence states 'Retrieves PricebookEntry records' and the later sentence says 'Get all product price entries'. Useful markers like [INSTRUCTIONS] and [READ-ONLY] help structure.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, but the description lists returned fields (product name, code, unit price, currency, active status). It explains the concept of price book entries. Minor inconsistency: says 'Get all product price entries' but a limit parameter exists, potentially confusing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and already fully describes parameters (pricebookId with format hint, limit with default). The description does not add extra details beyond what the schema provides, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves PricebookEntry records for a specific price book, listing the fields returned. It distinguishes from sibling tools by focusing on a single price book's entries, while others like sf_list_pricebooks list price books themselves.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly advises use cases: check pricing, compare across price books, verify product availability. It also tells how to obtain the required pricebookId via sf_list_pricebooks. No negative guidance, but positive context is strong.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and destructiveHint=false. The description adds '[READ-ONLY]' and explains return fields, which aligns with and supplements the annotations without contradiction.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (2-3 sentences) and front-loaded with key information. The '[INSTRUCTIONS]' prefix is slightly unusual but does not significantly detract.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a read-only query tool with 2 well-documented parameters and no output schema, the description adequately covers purpose, return fields, and usage context. It lacks sorting/pagination details but is sufficient for the complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, baseline 3. The description adds slight clarification ('Search SalesForce orders by order number or account name'), but the schema already describes the 'query' parameter adequately.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it queries Order sObjects, lists return fields, and explicitly differentiates from siblings like sf_orders_by_status and sf_search_products by specifying search keys (order number or account name).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context: 'when the user asks about customer orders, wants to look up a specific order number, or needs to review order history.' It does not include explicit when-not-to-use statements, but the context is sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so the description's addition of 'READ-ONLY' is redundant but consistent. The description adds context about the standard price book and the purpose of additional price books, which is helpful beyond annotations. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is structured with an initial instruction block and a summary. It is somewhat verbose but front-loads key information. Every sentence adds value, though could be slightly shorter.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (single optional parameter, no output schema), the description covers its purpose, fields returned, and usage context thoroughly. It explains the significance of the standard price book and use cases for additional price books, making it complete for an AI agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter is 'limit', which is fully described in the schema (maximum results, default 20). The description does not add any additional meaning or constraints to this parameter. With 100% schema coverage, baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool retrieves Pricebook2 records, lists specific fields (name, description, active status, IsStandard), and explains the concept of standard vs. additional price books. It distinguishes from sibling tool sf_pricebook_entries by implying this tool is for price book records themselves, not entries.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines4/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description advises using the tool to find price book IDs before viewing entries, providing a clear use case. However, it does not explicitly state when not to use this tool or contrast with other siblings like sf_products_by_family. The guidance is present but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. Description adds that it filters 'active' records and marks [READ-ONLY], reinforcing the safe read-only behavior and adding context about record status.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Concise two-paragraph structure with front-loaded purpose and usage. Every sentence adds value; no redundant or vague statements.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple schema and annotations, the description covers purpose, usage, parameter hints, and record status (active). Lacking return format is acceptable without output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema provides descriptions for both parameters (family and limit) with examples and default. Description does not add significant new meaning beyond the schema, so baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly specifies 'Filters active Product2 records by the Family field' and provides examples like 'Hardware, Software, Services'. It distinguishes from sibling tools like sf_search_products by focusing on category-level browsing.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly states when to use: 'when the user asks about products in a specific category, wants a category-level view, or needs to browse the catalog by family'. This provides clear guidance for agent decision-making.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and destructiveHint=false. Description reinforces with '[READ-ONLY]' and adds context that it retrieves specific fields, confirming safe behavior. No contradictions.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness4/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is clear but slightly verbose with a bracketed instruction block. It could be more concise, but overall concise enough.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple read tool with one required parameter, the description covers purpose, usage, and return fields. No output schema is needed as description lists returned fields. Complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters3/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with one parameter (orderId) described. Description does not add new parameter details, but the schema is sufficient. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states it retrieves OrderItem records for a specific order, listing product name, quantity, unit price, total price, and description. This differentiates it from sibling tools like sf_search_products (search) and sf_orders_by_status (order-level).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicit usage scenarios: 'Use when the user asks "what is in this order?", needs to review order composition, or wants to verify pricing before activation.' This provides clear when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![salesforce-commerce-mcp MCP server](https://glama.ai/mcp/servers/vinkius-labs/salesforce-commerce-mcp/badges/card.svg)](https://glama.ai/mcp/servers/vinkius-labs/salesforce-commerce-mcp)

Score Badge

Copy to your README.md:

[![salesforce-commerce-mcp MCP server](https://glama.ai/mcp/servers/vinkius-labs/salesforce-commerce-mcp/badges/score.svg)](https://glama.ai/mcp/servers/vinkius-labs/salesforce-commerce-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/vinkius-labs/salesforce-commerce-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server