Salesforce MCP Server

Search for Salesforce standard and custom objects by name pattern. Examples: 'Account' will find Account, AccountHistory; 'Order' will find WorkOrder, ServiceOrder__c etc.

Get detailed schema metadata including all fields, relationships, and field properties of any Salesforce object. Examples: 'Account' shows all Account fields including custom fields; 'Case' shows all Case fields including relationships to Account, Contact etc.

Query records from any Salesforce object using SOQL, including relationship queries. NOTE: For queries with GROUP BY, aggregate functions (COUNT, SUM, AVG, etc.), or HAVING clauses, use salesforce_aggregate_query instead. Examples: 1. Parent-to-child query (e.g., Account with Contacts): - objectName: "Account" - fields: ["Name", "(SELECT Id, FirstName, LastName FROM Contacts)"] 2. Child-to-parent query (e.g., Contact with Account details): - objectName: "Contact" - fields: ["FirstName", "LastName", "Account.Name", "Account.Industry"] 3. Multiple level query (e.g., Contact -> Account -> Owner): - objectName: "Contact" - fields: ["Name", "Account.Name", "Account.Owner.Name"] 4. Related object filtering: - objectName: "Contact" - fields: ["Name", "Account.Name"] - whereClause: "Account.Industry = 'Technology'" Note: When using relationship fields: - Use dot notation for parent relationships (e.g., "Account.Name") - Use subqueries in parentheses for child relationships (e.g., "(SELECT Id FROM Contacts)") - Custom relationship fields end in "__r" (e.g., "CustomObject__r.Name")

Execute SOQL queries with GROUP BY, aggregate functions, and statistical analysis. Use this tool for queries that summarize and group data rather than returning individual records. NOTE: For regular queries without GROUP BY or aggregates, use salesforce_query_records instead. This tool handles: 1. GROUP BY queries (single/multiple fields, related objects, date functions) 2. Aggregate functions: COUNT(), COUNT_DISTINCT(), SUM(), AVG(), MIN(), MAX() 3. HAVING clauses for filtering grouped results 4. Date/time grouping: CALENDAR_YEAR(), CALENDAR_MONTH(), CALENDAR_QUARTER(), FISCAL_YEAR(), FISCAL_QUARTER() Examples: 1. Count opportunities by stage: - objectName: "Opportunity" - selectFields: ["StageName", "COUNT(Id) OpportunityCount"] - groupByFields: ["StageName"] 2. Analyze cases by priority and status: - objectName: "Case" - selectFields: ["Priority", "Status", "COUNT(Id) CaseCount", "AVG(Days_Open__c) AvgDaysOpen"] - groupByFields: ["Priority", "Status"] 3. Count contacts by account industry: - objectName: "Contact" - selectFields: ["Account.Industry", "COUNT(Id) ContactCount"] - groupByFields: ["Account.Industry"] 4. Quarterly opportunity analysis: - objectName: "Opportunity" - selectFields: ["CALENDAR_YEAR(CloseDate) Year", "CALENDAR_QUARTER(CloseDate) Quarter", "SUM(Amount) Revenue"] - groupByFields: ["CALENDAR_YEAR(CloseDate)", "CALENDAR_QUARTER(CloseDate)"] 5. Find accounts with more than 10 opportunities: - objectName: "Opportunity" - selectFields: ["Account.Name", "COUNT(Id) OpportunityCount"] - groupByFields: ["Account.Name"] - havingClause: "COUNT(Id) > 10" Important Rules: - All non-aggregate fields in selectFields MUST be included in groupByFields - Use whereClause to filter rows BEFORE grouping - Use havingClause to filter AFTER grouping (for aggregate conditions) - ORDER BY can only use fields from groupByFields or aggregate functions - OFFSET is not supported with GROUP BY in Salesforce

Perform data manipulation operations on Salesforce records: - insert: Create new records - update: Modify existing records (requires Id) - delete: Remove records (requires Id) - upsert: Insert or update based on external ID field Examples: Insert new Accounts, Update Case status, Delete old records, Upsert based on custom external ID

Create new custom objects or modify existing ones in Salesforce: - Create: New custom objects with fields, relationships, and settings - Update: Modify existing object settings, labels, sharing model Examples: Create Customer_Feedback__c object, Update object sharing settings Note: Changes affect metadata and require proper permissions

Create new custom fields or modify existing fields on any Salesforce object: - Field Types: Text, Number, Date, Lookup, Master-Detail, Picklist etc. - Properties: Required, Unique, External ID, Length, Scale etc. - Relationships: Create lookups and master-detail relationships - Automatically grants Field Level Security to System Administrator (or specified profiles) Examples: Add Rating__c picklist to Account, Create Account lookup on Custom Object Note: Use grantAccessTo parameter to specify profiles, defaults to System Administrator

Manage Field Level Security (Field Permissions) for custom and standard fields. - Grant or revoke read/edit access to fields for specific profiles or permission sets - View current field permissions - Bulk update permissions for multiple profiles Examples: 1. Grant System Administrator access to a field 2. Give read-only access to a field for specific profiles 3. Check which profiles have access to a field

Search across multiple Salesforce objects using SOSL (Salesforce Object Search Language). Examples: 1. Basic search across all objects: { "searchTerm": "John", "objects": [ { "name": "Account", "fields": ["Name"], "limit": 10 }, { "name": "Contact", "fields": ["FirstName", "LastName", "Email"] } ] } 2. Advanced search with filters: { "searchTerm": "Cloud*", "searchIn": "NAME FIELDS", "objects": [ { "name": "Account", "fields": ["Name", "Industry"], "orderBy": "Name DESC", "where": "Industry = 'Technology'" } ], "withClauses": [ { "type": "NETWORK", "value": "ALL NETWORKS" }, { "type": "SNIPPET", "fields": ["Description"] } ] } Notes: - Use * and ? for wildcards in search terms - Each object can have its own WHERE, ORDER BY, and LIMIT clauses - Support for WITH clauses: DATA CATEGORY, DIVISION, METADATA, NETWORK, PRICEBOOKID, SNIPPET, SECURITY_ENFORCED - "updateable" and "viewable" options control record access filtering

Read Apex classes from Salesforce. Examples: 1. Read a specific Apex class by name: { "className": "AccountController" } 2. List all Apex classes with an optional name pattern: { "namePattern": "Controller" } 3. Get metadata about Apex classes: { "includeMetadata": true, "namePattern": "Trigger" } 4. Use wildcards in name patterns: { "namePattern": "Account*Cont*" } Notes: - When className is provided, the full body of that specific class is returned - When namePattern is provided, all matching class names are returned (without body) - Use includeMetadata to get additional information like API version, length, and last modified date - If neither className nor namePattern is provided, all Apex class names will be listed - Wildcards are supported in namePattern: * (matches any characters) and ? (matches a single character)

Create or update Apex classes in Salesforce. Examples: 1. Create a new Apex class: { "operation": "create", "className": "AccountService", "apiVersion": "58.0", "body": "public class AccountService { public static void updateAccounts() { /* implementation */ } }" } 2. Update an existing Apex class: { "operation": "update", "className": "AccountService", "body": "public class AccountService { public static void updateAccounts() { /* updated implementation */ } }" } Notes: - The operation must be either 'create' or 'update' - For 'create' operations, className and body are required - For 'update' operations, className and body are required - apiVersion is optional for 'create' (defaults to the latest version) - The body must be valid Apex code - The className in the body must match the className parameter - Status information is returned after successful operations

Read Apex triggers from Salesforce. Examples: 1. Read a specific Apex trigger by name: { "triggerName": "AccountTrigger" } 2. List all Apex triggers with an optional name pattern: { "namePattern": "Account" } 3. Get metadata about Apex triggers: { "includeMetadata": true, "namePattern": "Contact" } 4. Use wildcards in name patterns: { "namePattern": "Account*" } Notes: - When triggerName is provided, the full body of that specific trigger is returned - When namePattern is provided, all matching trigger names are returned (without body) - Use includeMetadata to get additional information like API version, object type, and last modified date - If neither triggerName nor namePattern is provided, all Apex trigger names will be listed - Wildcards are supported in namePattern: * (matches any characters) and ? (matches a single character)

Create or update Apex triggers in Salesforce. Examples: 1. Create a new Apex trigger: { "operation": "create", "triggerName": "AccountTrigger", "objectName": "Account", "apiVersion": "58.0", "body": "trigger AccountTrigger on Account (before insert, before update) { /* implementation */ }" } 2. Update an existing Apex trigger: { "operation": "update", "triggerName": "AccountTrigger", "body": "trigger AccountTrigger on Account (before insert, before update, after update) { /* updated implementation */ }" } Notes: - The operation must be either 'create' or 'update' - For 'create' operations, triggerName, objectName, and body are required - For 'update' operations, triggerName and body are required - apiVersion is optional for 'create' (defaults to the latest version) - The body must be valid Apex trigger code - The triggerName in the body must match the triggerName parameter - The objectName in the body must match the objectName parameter (for 'create') - Status information is returned after successful operations

Execute anonymous Apex code in Salesforce. Examples: 1. Execute simple Apex code: { "apexCode": "System.debug('Hello World');" } 2. Execute Apex code with variables: { "apexCode": "List<Account> accounts = [SELECT Id, Name FROM Account LIMIT 5]; for(Account a : accounts) { System.debug(a.Name); }" } 3. Execute Apex with debug logs: { "apexCode": "System.debug(LoggingLevel.INFO, 'Processing accounts...'); List<Account> accounts = [SELECT Id FROM Account LIMIT 10]; System.debug(LoggingLevel.INFO, 'Found ' + accounts.size() + ' accounts');", "logLevel": "DEBUG" } Notes: - The apexCode parameter is required and must contain valid Apex code - The code is executed in an anonymous context and does not persist - The logLevel parameter is optional (defaults to 'DEBUG') - Execution results include compilation success/failure, execution success/failure, and debug logs - For security reasons, some operations may be restricted based on user permissions - This tool can be used for data operations or updates when there are no other specific tools available - When users request data queries or updates that aren't directly supported by other tools, this tool can be used if the operation is achievable using Apex code

Manage debug logs for Salesforce users - enable, disable, or retrieve logs. Examples: 1. Enable debug logs for a user: { "operation": "enable", "username": "[email protected]", "logLevel": "DEBUG", "expirationTime": 30 } 2. Disable debug logs for a user: { "operation": "disable", "username": "[email protected]" } 3. Retrieve debug logs for a user: { "operation": "retrieve", "username": "[email protected]", "limit": 5 } 4. Retrieve a specific log with full content: { "operation": "retrieve", "username": "[email protected]", "logId": "07L1g000000XXXXEAA0", "includeBody": true } Notes: - The operation must be one of: 'enable', 'disable', or 'retrieve' - The username parameter is required for all operations - For 'enable' operation, logLevel is optional (defaults to 'DEBUG') - Log levels: NONE, ERROR, WARN, INFO, DEBUG, FINE, FINER, FINEST - expirationTime is optional for 'enable' operation (minutes until expiration, defaults to 30) - limit is optional for 'retrieve' operation (maximum number of logs to return, defaults to 10) - logId is optional for 'retrieve' operation (to get a specific log) - includeBody is optional for 'retrieve' operation (to include the full log content, defaults to false) - The tool validates that the specified user exists before performing operations - If logLevel is not specified when enabling logs, the tool will ask for clarification