Enables management of Salesforce orders, returns, and cases, including checking order status and tracking, creating return orders, managing return order line items, creating and updating support cases, and automating return label emails.
Sends formatted alerts and notifications to Slack channels for real-time updates on order management activities.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Salesforce Order Concierge check the status of order 00000100"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A Model Context Protocol (MCP) server that provides Salesforce order management capabilities for Claude Desktop, including order status checking, return creation, case management, and Slack notifications.
This MCP server enables Claude Desktop to interact with Salesforce for:
Order status checking with shipping details and tracking information
Return order creation using standard Salesforce ReturnOrder objects
Case management integration for customer service escalation
Slack notification system for real-time alerts
Return label email automation for customer convenience
Related MCP server: Salesforce MCP Server
check_order_status - Check order status, shipping details, and tracking information
create_return - Create return orders using standard Salesforce objects
email_return_label - Email return shipping labels to customers
update_case_status - Update case status with priority and assignment changes
create_case_from_return - Create support cases from return orders
send_slack_alert - Send formatted alerts to Slack channels
npm install
npm run buildIf you want to use the enhanced features:
# Authenticate to your Salesforce org
sf org login web --alias MyOrg
# Deploy custom fields and flows
sf project deploy start --target-org MyOrgAdd to your Claude Desktop claude_desktop_config.json:
{
"mcpServers": {
"salesforce-order-concierge": {
"command": "node",
"args": ["dist/index.js"],
"cwd": "/path/to/sf_mcp_oc",
"env": {
"SF_LOGIN_URL": "https://login.salesforce.com",
"SF_USERNAME": "your-salesforce-username@example.com",
"SF_PASSWORD": "your-salesforce-password",
"SF_SECURITY_TOKEN": "your-salesforce-security-token",
"SLACK_WEBHOOK_URL": "your-slack-webhook-url-optional"
}
}
}
}After adding the configuration, restart Claude Desktop to load the MCP server.
The MCP Inspector is a powerful tool for testing and debugging MCP servers. Here's how to use it:
npx @modelcontextprotocol/inspectorStart the Inspector:
npx @modelcontextprotocol/inspectorConfigure Connection:
Server Command: node
Arguments: ["dist/index.js"]
Working Directory: /path/to/sf_mcp_oc
Environment Variables:
SF_LOGIN_URL=https://login.salesforce.com
SF_USERNAME=your-username@example.com
SF_PASSWORD=your-password
SF_SECURITY_TOKEN=your-token
SLACK_WEBHOOK_URL=your-webhook-urlTest Tools:
Click "Connect" to establish connection
Browse available tools in the left panel
Test each tool with sample data
View requests/responses in real-time
Check Order Status:
{
"orderId": "00000100"
}Create Return:
{
"orderId": "801xx0000000001",
"lineItemId": "802xx0000000001",
"reason": "Defective",
"quantity": 1,
"description": "Product stopped working"
}Send Slack Alert:
{
"message": "Test alert from MCP Inspector",
"priority": "info"
}Connection Issues: Check environment variables and Salesforce credentials
Tool Failures: Review error messages in the inspector's response panel
Permissions: Ensure your Salesforce user has access to required objects
Network: Verify Salesforce and Slack connectivity
Salesforce org with Service Cloud or Field Service license
Order Management enabled
API access for the configured user
Standard objects: Order, OrderItem, ReturnOrder, ReturnOrderLineItem, Case
Node.js 18+ installed
Salesforce CLI (optional, for metadata deployment)
Claude Desktop application
Variable | Required | Description |
| Yes | Salesforce login URL ( |
| Yes | Salesforce username |
| Yes | Salesforce password |
| Yes | Salesforce security token |
| No | Slack webhook URL for notifications |
ReturnOrder - Standard Salesforce object for return management
ReturnOrderLineItem - Individual return items
Case - Customer service integration
Order/OrderItem - Order relationships
ReturnOrder.LabelEmailSent__c - Tracks if return label was emailed
ReturnOrder.LabelEmailSentDate__c - Email timestamp
"Server disconnected while setting up"
# Check if server builds successfully
npm run build
# Verify file permissions
chmod +x dist/index.js
# Test server startup
node dist/index.js"Invalid login"
Verify Salesforce credentials
Check security token (get new one from Setup ā My Personal Information)
Use correct login URL for your org type
"Object not found" errors
Ensure Service Cloud license is active
Enable Order Management in Setup ā Sales ā Order Settings
Verify user has access to ReturnOrder objects
Tool execution failures
Test with MCP Inspector to see detailed error messages
Check Salesforce debug logs
Verify required fields are populated
Use MCP Inspector for detailed debugging
Check Claude Desktop logs for connection issues
Review Salesforce debug logs for API errors
Test Salesforce connectivity with simple SOQL queries
sf_mcp_oc/
āāā src/
ā āāā index.ts # Main MCP server
ā āāā salesforce-client.ts # Salesforce API client
ā āāā types.ts # TypeScript schemas
āāā force-app/main/default/ # Salesforce metadata
ā āāā objects/ReturnOrder/ # Custom fields
ā āāā flows/ # Automation flows
āāā dist/ # Compiled JavaScript
āāā package.json # Node.js dependencies
āāā tsconfig.json # TypeScript config
āāā CLAUDE.md # Project instructionsNever commit credentials to version control
Use environment variables for all sensitive data
Rotate Salesforce security tokens regularly
Use dedicated API users with minimal required permissions
MIT License - see LICENSE file for details.
Check an order's shipping status, carrier, tracking number, and ETA
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order ID or order number to check |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the tool checks information but doesn't specify if it's read-only, requires authentication, has rate limits, or what the response format looks like. This leaves significant gaps for a tool that likely queries external systems.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that front-loads the core purpose without any wasted words. It directly communicates what the tool does in a clear and structured manner.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's low complexity (one parameter, no output schema, no annotations), the description is minimally adequate but incomplete. It lacks behavioral details and usage context, which are important for an agent to operate effectively, especially without annotations to fill in gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents the single parameter 'orderId'. The description doesn't add any meaning beyond what the schema provides, such as format examples or constraints, but the high coverage justifies the baseline score.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('check') and resources ('order's shipping status, carrier, tracking number, and ETA'), making it immediately understandable. However, it doesn't explicitly differentiate from sibling tools like 'update_case_status' or 'create_return', which prevents a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for use, or exclusions, leaving the agent to infer usage from the purpose alone without explicit direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a case from an existing return order for tracking and follow-up
| Name | Required | Description | Default |
|---|---|---|---|
| returnOrderId | Yes | The return order ID to create a case from |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries full burden. It states the tool creates a case, implying a write operation, but doesn't disclose behavioral traits such as permissions needed, whether the case is editable, what happens if the return order is invalid, or any rate limits. The phrase 'for tracking and follow-up' adds minimal context but doesn't compensate for the lack of annotations.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that states the purpose without waste. It's front-loaded with the core action, though it could be slightly more structured (e.g., separating purpose from outcome). Every word earns its place, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the complexity (a write operation with no annotations and no output schema), the description is incomplete. It lacks details on what the tool returns, error conditions, or side effects. Without annotations or output schema, the description should provide more behavioral context, but it only covers basic purpose, leaving gaps for agent invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, with the parameter 'returnOrderId' fully documented in the schema. The description doesn't add any meaning beyond the schema, such as format examples or constraints. With high schema coverage, the baseline is 3, as the description doesn't compensate but doesn't detract either.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a case') and the source ('from an existing return order'), specifying both verb and resource. It distinguishes from siblings like 'create_return' (different resource) and 'update_case_status' (different action), though it doesn't explicitly contrast them. The purpose is specific but lacks explicit sibling differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a valid return order), exclusions, or comparisons to siblings like 'create_return' or 'update_case_status'. The description implies usage for 'tracking and follow-up', but this is vague and not actionable for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a return order for a single line item in an order using standard Salesforce objects
| Name | Required | Description | Default |
|---|---|---|---|
| orderId | Yes | The order ID containing the item to return | |
| lineItemId | Yes | The specific line item ID to return | |
| reason | Yes | Reason for the return | |
| quantity | Yes | Quantity to return | |
| description | No | Optional additional description for the return |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. While 'Create' implies a write operation, it doesn't specify permissions required, whether the action is reversible, potential side effects (e.g., inventory updates), or response format. This is inadequate for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence that directly states the tool's purpose without unnecessary words. It's front-loaded with the core action, though it could be slightly more structured by hinting at key parameters or outcomes.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with no annotations and no output schema, the description is incomplete. It lacks behavioral details (e.g., what happens after creation, error conditions), usage context relative to siblings, and output expectations, leaving significant gaps for an agent to operate effectively.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents all parameters thoroughly (e.g., orderId, lineItemId, reason with enum values, quantity with minimum). The description adds no additional parameter semantics beyond what the schema provides, meeting the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Create a return order') and the resource ('for a single line item in an order using standard Salesforce objects'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'create_case_from_return' or 'email_return_label', which might handle related but different aspects of returns.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing order), exclusions, or how it relates to siblings like 'create_case_from_return' or 'email_return_label', leaving the agent to infer usage context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Email the customer a PDF return label for an approved return order
| Name | Required | Description | Default |
|---|---|---|---|
| returnOrderId | Yes | The return order ID for which to send the label | |
| customerEmail | Yes | Customer email address to send the label to |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Email') and outcome ('send the label') but lacks details on permissions, rate limits, error handling, or what happens if the email fails. This is a significant gap for a mutation tool with zero annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words, clearly front-loading the core action and purpose. Every element ('Email', 'PDF return label', 'approved return order') earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's mutation nature (emailing a label), lack of annotations, and no output schema, the description is incomplete. It doesn't address behavioral aspects like side effects, success/failure responses, or integration with sibling tools, leaving gaps for agent understanding.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 100%, so the schema already documents both parameters fully. The description adds no additional meaning beyond what the schema provides, such as format examples or constraints, meeting the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Email'), resource ('PDF return label'), and context ('for an approved return order'), making the tool's purpose immediately understandable. It specifies the verb, object, and scope, though it doesn't explicitly differentiate from sibling tools like 'create_return' or 'send_slack_alert'.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides minimal guidance, mentioning only that the return order must be 'approved' but not clarifying when to use this tool versus alternatives like 'create_return' or 'send_slack_alert'. No explicit when-not-to-use scenarios or prerequisites beyond approval are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a Slack alert notification
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | The alert message to send | |
| priority | No | Alert priority level (optional, defaults to info) | |
| caseId | No | Related case ID (optional) | |
| customFields | No | Additional custom fields to include in the alert (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure but offers minimal information. It mentions sending an alert but doesn't cover permissions needed, rate limits, what channel/recipient receives it, whether it's synchronous/asynchronous, or error handling. This leaves significant gaps for a notification tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise at just four words, front-loading the core purpose with zero wasted text. Every word earns its place, making it highly efficient.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with 4 parameters, no annotations, and no output schema, the description is insufficiently complete. It lacks context about the Slack environment (e.g., channel, token requirements), behavioral details, and usage scenarios, leaving the agent with inadequate guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all parameters. The description adds no additional parameter semantics beyond what's in the schema, meeting the baseline score of 3 for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Send') and resource ('a Slack alert notification'), making the tool's purpose immediately understandable. However, it doesn't differentiate this tool from potential sibling notification tools (though none exist in the provided sibling list), keeping it from a perfect score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or contextual constraints. It simply states what the tool does without indicating appropriate scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a case status with optional priority and assignment changes
| Name | Required | Description | Default |
|---|---|---|---|
| caseId | Yes | The case ID to update | |
| status | Yes | New case status | |
| reason | No | Reason for status change (optional) | |
| priority | No | Case priority (optional) | |
| assignedTo | No | User ID or username to assign case to (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden for behavioral disclosure. It indicates this is a mutation tool ('update'), but doesn't mention permissions required, whether changes are reversible, side effects, rate limits, or what happens to existing data not mentioned. For a mutation tool with zero annotation coverage, this is a significant gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, efficient sentence with zero wasted words. It's appropriately sized for a tool with good schema documentation and gets straight to the point without unnecessary elaboration.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a mutation tool with 5 parameters and no annotations or output schema, the description is inadequate. It doesn't explain what the tool returns, error conditions, or important behavioral aspects. While the schema covers parameter documentation well, the description fails to provide the contextual information needed for safe and effective use of this update operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema already documents all 5 parameters thoroughly. The description adds minimal value beyond the schemaāit mentions 'optional priority and assignment changes' which corresponds to the 'priority' and 'assignedTo' parameters, but doesn't provide additional context about their meaning or usage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the verb ('update') and resource ('case status'), making the purpose understandable. However, it doesn't distinguish this tool from potential sibling tools that might also modify cases, as the sibling list provided doesn't include obvious alternatives for case status updates.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives, prerequisites, or constraints. While it mentions 'optional priority and assignment changes,' this doesn't constitute usage guidelinesāit's just listing optional parameters without context about when they're appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Every tool has a clearly distinct purpose with no ambiguity. Tools like check_order_status, create_return, and email_return_label each target specific, non-overlapping actions in the order and return workflow, while send_slack_alert and update_case_status serve separate notification and case management functions.
The naming follows a consistent verb_noun pattern throughout (e.g., check_order_status, create_return, update_case_status), with only minor deviations such as send_slack_alert using 'send' instead of a more domain-specific verb, but overall it remains highly readable and predictable.
With 6 tools, the server is well-scoped for its purpose of managing orders, returns, and cases. Each tool earns its place by covering distinct aspects of the workflow, from status checks to case creation and notifications, without feeling bloated or insufficient.
The tool set provides strong coverage for order and return workflows, including status checks, return creation, case management, and notifications. Minor gaps exist, such as no direct tool for creating or updating orders themselves, but agents can likely work around this using existing tools like create_return and update_case_status.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Salesforce-grounded retrieval, diagnoses, and a vetted-Force marketplace for MCP clients.
Connect Claude to your Platform7n workspaces ā chat, links, and tasks. One-click OAuth.
One workspace of tools for Claude and ChatGPT: connect 600+ apps, generate media, build tools.
Surface customer & prospect context from Slack, email, transcripts and tickets in any MCP client.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/gellasangameshgupta/sf_mcp_oc'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
