Salesforce MCP Server
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| READ_ONLY | No | When set to 'true', prevents execution of Apex code (anonymous execution and tests). | false |
| ALLOWED_ORGS | No | Comma-separated list of allowed org aliases. Use 'ALL' for unrestricted access. | ALL |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| logging | {} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
| completions | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| execute_anonymous_apexB | Execute Apex code in a Salesforce Org. This command allows you to run Apex code directly against a specified Salesforce Org. The code is executed in the context of the Org, and the results are returned in JSON format. You can use this command to test Apex code snippets, run batch jobs, or perform other Apex-related tasks. You can review the debug logs of the execution to see the results of the code execution. |
| run_apex_testsB | Run Apex tests in a Salesforce Org. This command allows you to execute unit tests with various options including test level, specific classes, suites, and code coverage collection. Tests can be run synchronously or asynchronously. Use this to validate your Apex code and ensure proper test coverage. |
| get_apex_test_resultsA | Retrieve results from a previous asynchronous Apex test run. Use this command with a test run ID to get detailed test results including pass/fail status, error messages, stack traces, and optionally code coverage information. |
| get_apex_code_coverageA | Get code coverage information for a Salesforce Org. This command allows you to retrieve org-wide coverage percentage or coverage details from a specific test run. Use this to monitor and ensure your code meets the 75% coverage requirement. |
| generate_classC | Generates the Apex *.cls file and associated metadata file. These files must contained in a parent directory called "classes" in your package directory. Either run this command existing directory of this name, or use the --output-dir flag to generate one or point to an existing one. |
| generate_triggerB | Generates the Apex trigger *.trigger file and associated metadata file. These files must be contained in a parent directory called "triggers" in your package directory. Either run this command from an existing directory of this name, or use the --output-dir flag to generate one or point to an existing one. If you don't specify the --sobject flag, the .trigger file contains the generic placeholder SOBJECT; replace it with the Salesforce object you want to generate a trigger for. If you don't specify --event, "before insert" is used. |
| apex_log_listB | Fetch the list of apex debug logs returning the logs with their IDs. |
| apex_get_logB | Fetch the specified log or given number of most recent logs from the org. |
| list_connected_salesforce_orgsA | List connected Salesforce Orgs. This command retrieves a list of all Salesforce Orgs that are currently connected to the Salesforce CLI. The results are returned in JSON format, providing details about each Org, including its alias, username, and other metadata. Use this command to see which Salesforce Orgs you have access to and can interact with using the Salesforce CLI. Usernames, org IDs and instance URLs in the result are masked for privacy; refer to orgs by alias when passing targetOrg to other tools. |
| login_into_orgA | Authenticate and login to a Salesforce org via web browser. This command opens a browser window for OAuth authentication flow, allowing you to securely connect to a Salesforce org. After successful authentication, the org credentials are stored locally by the Salesforce CLI for future use. Use isProduction=true for production/developer orgs (login.salesforce.com) or isProduction=false for sandboxes/scratch orgs (test.salesforce.com). The alias parameter creates a convenient shorthand name for accessing this org in subsequent commands. IMPORTANT: This tool requires both 'alias' and 'isProduction' parameters to be provided before execution - do not proceed until all required parameters are supplied. |
| assign_permission_setC | Assign a permission set to one or more org users. To specify an alias for the --target-org or --on-behalf-of flags, use the CLI username alias, such as the one you set with the 'alias set' command. Don't use the value of the Alias field of the User Salesforce object for the org user. To assign multiple permission sets, specify multiple names in the permissionSetNames array. Enclose names that contain spaces in the array elements. The same syntax applies to onBehalfOf array for specifying multiple users. |
| assign_permission_set_licenseB | Assign a permission set license to one or more org users. To specify an alias for the --target-org or --on-behalf-of flags, use the CLI username alias, such as the one you set with the 'alias set' command. Don't use the value of the Alias field of the User Salesforce object for the org user. To assign multiple permission set licenses, specify multiple names in the licenseNames array. Enclose names that contain spaces in the array elements. The same syntax applies to onBehalfOf array for specifying multiple users. |
| display_userB | Display information about a Salesforce user. Output includes the profile name, org ID, access token, instance URL, login URL, and alias if applicable. The username, org ID, instance URL and login URL are masked for privacy. The displayed alias is local and different from the Alias field of the User sObject record of the new user, which you set in the Setup UI. |
| list_metadataA | List the metadata components and properties of a specified type. Use this command to identify individual components in your manifest file or if you want a high-level view of particular metadata types in your org. For example, you can use this command to return a list of names of all the CustomObject or Layout components in your org, then use this information in a retrieve command that returns a subset of these components. The username that you use to connect to the org must have the Modify All Data or Modify Metadata Through Metadata API Functions permission. |
| list_metadata_typesA | Display details about the metadata types that are enabled for your org. The information includes Apex classes and triggers, custom objects, custom fields on standard objects, tab sets that define an app, and many other metadata types. Use this information to identify the syntax needed for a element in a manifest file (package.xml). The username that you use to connect to the org must have the Modify All Data or Modify Metadata Through Metadata API Functions permission. |
| logoutA | Log out of a Salesforce org. Use targetOrg to logout of a specific org, or set all to true to logout of all orgs. The logout is performed with --no-prompt flag to avoid confirmation prompts. Be careful! If you log out of a scratch org without having access to its password, you can't access the scratch org again, either through the CLI or the Salesforce UI. |
| openA | Open your Salesforce org in a browser. To open a specific page, specify the portion of the URL after 'https://mydomain.my.salesforce.com' as the path value. Use sourceFile to open ApexPage, FlexiPage, Flow, or Agent metadata from your local project in the associated Builder. |
| get_default_orgA | Get the current default target org configured in the Salesforce CLI. Returns only the org's alias, which is used as the default when no targetOrg is specified in other tool calls. If the default org has no alias, a masked username is returned with a hint asking the user to set an alias; usernames, org IDs and instance URLs are never returned. |
| set_default_orgA | Set the default target org for the Salesforce CLI. Once set, all tools will use this org by default when no targetOrg is specified. The value persists across sessions. |
| clear_default_orgA | Clear the default target org from the Salesforce CLI configuration. After clearing, all tools will require an explicit targetOrg parameter until a new default is set. |
| open_recordB | Opens a Salesforce record in a browser. |
| create_recordB | Create a new record in a Salesforce org using the REST API. Returns the ID of the created record on success. Input must be a JSON object with keys: sObject (string), recordJson (string), and optionally targetOrg (string). |
| update_recordB | Update an existing record in a Salesforce org using the REST API. Updates specified fields on the record. Input must be a JSON object with keys: sObject (string), recordId (string), recordJson (string), and optionally targetOrg (string). |
| delete_recordA | Delete a record from a Salesforce org using the REST API. Permanently removes the specified record. Input must be a JSON object with keys: sObject (string), recordId (string), and optionally targetOrg (string). |
| sobject_listA | List all standard and custom objects in a Salesforce Org. This command retrieves a list of all standard and custom objects available in the specified Salesforce Org. The results are returned in JSON format, providing details about each object, including its name, label, and other metadata. Use this command to explore the objects in your Salesforce Org and understand their structure and properties, especially if asked to work with specific objects in your Apex code or SOQL queries and you don't know their API names. Always execute this tool before writing Apex code or SOQL queries to ensure you have the correct object names. |
| sobject_describeA | Describe a Salesforce SObject. This command retrieves detailed metadata about a specific Salesforce SObject, including its fields, relationships, and other properties. The results are returned in JSON format, providing a comprehensive view of the SObject's structure. Use this command to understand the schema of a specific SObject, which is especially useful when writing Apex code or SOQL queries that interact with that SObject. Always execute this tool before querying or manipulating records in the SObject to ensure you have the correct field names and types. |
| query_recordsA | Query records from a SINGLE Salesforce object using structured field conditions. Use this for precise queries on ONE object with specific field criteria (e.g., Status = 'Open', Amount > 1000). NOT for text searches across multiple objects - use search_records for that. This executes SOQL queries with SELECT, WHERE, ORDER BY, and LIMIT clauses on a single SObject. The results are returned in JSON format. IMPORTANT: Always execute the |
| query_records_to_fileA | Query records from a Salesforce SObject and save to a file. This command allows you to execute a SOQL query against a specified Salesforce SObject in a given Org and save the results to a file. You can specify the SELECT clause (fields, functions like COUNT(), aggregations, etc.), an optional WHERE clause, and save the results in various formats. The results can be saved in CSV format by default, or in other formats if specified. IMPORTANT: Always execute the |
| get_server_permissionsC | Get current server permission settings |
| run_code_analyzerA | Analyze code for quality and security issues. Run list_code_analyzer_rules first to select appropriate rules for ruleSelector parameter. |
| list_code_analyzer_rulesA | List available code analysis rules with details. Use to determine rules for code-analyzer run command. |
| scanner_runC | Scan codebase with security and quality rules. Defaults to all rules if none specified. |
| scanner_run_dfaC | Run Graph Engine for Apex data flow analysis. Detects complex security issues like SOQL/SQL injection. |
| package_installB | Install or upgrade a package version in a Salesforce org. Supports both package IDs (04t) and aliases with various configuration options. |
| package_uninstallC | Uninstall a second-generation package from the target org. Specify the package ID (starts with 04t) or alias for the package to uninstall. |
| schema_generate_tabC | Generate metadata source files for a new custom tab on a custom object. Custom tabs display custom object data in Salesforce navigation. |
| search_recordsA | Search for text across multiple Salesforce objects simultaneously. USE THIS TOOL when searching for records that mention, contain, or reference specific text (like company names, keywords, phrases) across different objects. This is the PRIMARY tool for text-based searches across your org - it's much more efficient than running multiple SOQL queries. Perfect for finding all records mentioning a competitor, customer name, or any text across Accounts, Opportunities, Cases, Contacts, etc. SOSL (Salesforce Object Search Language) performs full-text search across all searchable fields. |
| generate_componentC | Generate Lightning Web Components (LWC) or Aura components with customizable templates and output directories |
| deploy_startC | Deploy metadata to Salesforce org with test execution options. |
| install_skillA | Install the Salesforce MCP Server skill for Claude Code into the current working directory (.claude/skills/salesforce/SKILL.md). The skill provides domain-specific guidance on how to effectively use all 40 Salesforce tools, 5 prompts, and 5 resources together. Once installed, the skill persists across Claude Code sessions in this project and helps Claude choose the right tools, chain them into workflows, and avoid common Salesforce mistakes. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| soql_builder | Describe an SObject and help build a SOQL query step by step |
| apex_review | Fetch an Apex class from the org and perform a structured code review |
| org_health_check | Fetch org info, API limits, and test coverage to assess org health |
| deploy_checklist | Fetch org limits and coverage to generate a pre-deployment readiness checklist |
| debug_apex | Fetch an Apex debug log (by ID or most recent) and analyze it for errors and performance issues |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| server_permissions | Current server permission settings including read-only mode, allowed orgs, client browser mode, and default org (alias only) |
TDQS
Scored across 40 tools
Most tools target distinct Salesforce operations, but several overlap: run_code_analyzer, scanner_run, and scanner_run_dfa all perform code analysis; apex_get_log vs apex_log_list and query_records vs query_records_to_file require reading descriptions to distinguish. These overlaps keep the set from being cleanly disambiguated.
Tools are mostly snake_case, but ordering is inconsistent: verb_noun (create_record, list_metadata) mixes with noun_verb (sobject_list, apex_log_list, package_install, scanner_run, deploy_start). Some generic names like open and logout lack resource context, though the set remains readable.
40 tools is excessive for a single MCP server, even for the broad Salesforce domain. Several niche CLI wrappers could be consolidated, especially the code-analysis trio and the two query_records variants, making the surface feel bloated rather than well-scoped.
Coverage spans core Salesforce domains: org auth/config, record CRUD, SOQL/SOSL, metadata listing, Apex tests/execution, deployment, packages, code analysis, and logging. Minor gaps like metadata retrieve/update/delete and direct record get are workaroundable, so the surface is broadly complete.