Servidor de Protocolo de contexto de modelo (MCP) para proporcionar funcionalidad CLI de Salesforce a herramientas LLM como Claude Desktop.
Este servidor MCP encapsula la herramienta de línea de comandos Salesforce CLI ( sf ) y expone sus comandos como herramientas y recursos MCP, lo que permite a los agentes con tecnología LLM:
Ver información de ayuda sobre temas y comandos de Salesforce CLI
Ejecute comandos CLI de Salesforce con los parámetros adecuados
Aproveche las capacidades de Salesforce CLI en los flujos de trabajo de IA
Related MCP server: Salesforce CLI MCP Server
Node.js 18+ y npm
Salesforce CLI ( sf ) instalado y configurado
Sus credenciales de organización de Salesforce configuradas en la CLI
# Clone the repository
git clone <repository-url>
cd sfMcp
# Install dependencies
npm install# Basic usage
npm start
# With project roots
npm start /path/to/project1 /path/to/project2
# or using the convenience script
npm run with-roots /path/to/project1 /path/to/project2
# As an npx package with roots
npx -y codefriar/sf-mcp /path/to/project1 /path/to/project2El servidor MCP utiliza el transporte stdio, que se puede utilizar con clientes MCP como MCP Inspector o Claude Desktop.
Para configurar este MCP en la configuración .claude.json de Claude Desktop:
{
"tools": {
"salesforce": {
"command": "/path/to/node",
"args": [
"/path/to/sf-mcp/build/index.js",
"/path/to/project1",
"/path/to/project2"
]
}
}
}Usando el paquete npm directamente:
{
"tools": {
"salesforce": {
"command": "/path/to/npx",
"args": [
"-y",
"codefriar/sf-mcp",
"/path/to/project1",
"/path/to/project2"
]
}
}
}# Watch mode (recompiles on file changes)
npm run dev
# In another terminal
npm start [optional project roots...]Este servidor MCP proporciona comandos de Salesforce CLI como herramientas MCP. Detecta y registra automáticamente todos los comandos disponibles de Salesforce CLI e implementa específicamente los comandos más comunes.
sf_version : obtener la información de la versión de Salesforce CLI
sf_help : obtenga información de ayuda para los comandos CLI de Salesforce
sf_cache_clear - Borra la caché de descubrimiento de comandos
sf_cache_refresh - Actualizar la caché de descubrimiento de comandos
Para los comandos que requieren un contexto de proyecto de Salesforce (como las implementaciones), debe especificar el directorio del proyecto. El MCP admite varios directorios de proyecto (raíces), de forma similar al MCP del sistema de archivos.
Método 1: mediante argumentos de la línea de comandos
# Start the MCP with project roots
npm start /path/to/project1 /path/to/project2
# or
npx -y codefriar/sf-mcp /path/to/project1 /path/to/project2Cuando se configura de esta manera, las raíces se nombrarán automáticamente root1 , root2 , etc., y la primera se establecerá como predeterminada.
Método 2: Uso de herramientas MCP
sf_set_project_directory : establece un directorio de proyecto de Salesforce para usar con los comandos
Parámetros:
directory - Ruta a un directorio que contiene un archivo sfdx-project.json
name - (Opcional) Nombre para esta raíz del proyecto
description - (Opcional) Descripción de la raíz de este proyecto
isDefault - (Opcional) Establezca esta raíz como predeterminada para la ejecución del comando
sf_list_roots - Lista todas las raíces del proyecto configuradas
sf_detect_project_directory : intenta detectar el directorio del proyecto a partir de los mensajes del usuario
Ejemplo de uso:
# Set project directory with a name
sf_set_project_directory --directory=/path/to/your/sfdx/project --name=project1 --isDefault=true
# List all configured roots
sf_list_roots
# Or include in your message:
"Please deploy the apex code from the project in /path/to/your/sfdx/project to my scratch org"Método 3: Configuración de escritorio de Claude Configure las raíces del proyecto en .claude.json como se describe a continuación.
Puede ejecutar comandos en raíces de proyectos específicos:
# Using resource URI
sf://roots/project1/commands/project deploy start --sourcedir=force-app
# Using rootName parameter
sf_project_deploy_start --sourcedir=force-app --rootName=project1Se debe especificar el directorio del proyecto para comandos como implementaciones, recuperación de código fuente y otras operaciones específicas del proyecto. Si se configuran varias raíces, se usará la raíz predeterminada a menos que se especifique lo contrario.
Los siguientes comandos están implementados específicamente y se garantiza que funcionan:
sf_org_list - Lista de organizaciones de Salesforce
Parámetros: json , verbose
sf_auth_list_orgs - Lista de organizaciones de Salesforce autenticadas
Parámetros: json , verbose
sf_org_display - Mostrar detalles sobre una organización
Parámetros: targetusername , json
sf_org_open - Abre una organización en el navegador
Parámetros: targetusername , path , urlonly
sf_apex_run - Ejecutar código Apex anónimo
Parámetros: targetusername , file , apexcode , json
sf_apex_test_run - Ejecutar pruebas de Apex
Parámetros: targetusername , testnames , suitenames , classnames , json
sf_data_query - Ejecutar una consulta SOQL
Parámetros: targetusername , query , json
sf_schema_list_objects - Lista de sObjects en la organización
Parámetros: targetusername , json
sf_schema_describe : describe un objeto de Salesforce
Parámetros: targetusername , sobject , json
sf_project_deploy_start - Implementar la fuente en una organización
Parámetros: targetusername , sourcedir , json , wait
El servidor descubre todos los comandos CLI de Salesforce disponibles y los registra como herramientas con el formato: sf_<topic>_<command> .
Por ejemplo:
sf_apex_run - Ejecutar código Apex anónimo
sf_data_query - Ejecutar una consulta SOQL
Para los comandos de temas anidados, el nombre de la herramienta incluye la ruta completa con guiones bajos:
sf_apex_log_get - Obtener registros de Apex
sf_org_login_web - Iniciar sesión en una organización mediante el flujo web
El servidor también crea alias simplificados para comandos anidados comunes cuando es posible:
sf_get como alias para sf_apex_log_get
sf_web como alias para sf_org_login_web
Los comandos disponibles varían según los complementos CLI de Salesforce instalados.
Nota: La detección de comandos se almacena en caché para mejorar el rendimiento del inicio. Si instala nuevos complementos de SF CLI, utilice la herramienta
sf_cache_refreshpara actualizar la caché y, a continuación, reinicie el servidor.
Los siguientes recursos proporcionan documentación sobre Salesforce CLI:
sf://help - Documentación principal de la CLI
sf://topics/{topic}/help - Documentación de ayuda del tema
sf://commands/{command}/help - Documentación de ayuda de comandos
sf://topics/{topic}/commands/{command}/help - Documentación de ayuda sobre temas y comandos
sf://version - Información de la versión
sf://roots - Lista todas las raíces del proyecto configuradas
sf://roots/{root}/commands/{command} - Ejecutar un comando en una raíz de proyecto específica
Al iniciarse, el servidor busca una lista de comandos en caché (almacenada en ~/.sf-mcp/command-cache.json )
Si existe un caché válido, se utiliza para registrar comandos; de lo contrario, los comandos se descubren dinámicamente.
Durante el descubrimiento, el servidor consulta sf commands --json para obtener una lista completa de los comandos disponibles.
Los metadatos del comando (incluidos parámetros y descripciones) se extraen directamente de la salida JSON
Todos los comandos se registran como herramientas MCP con esquemas de parámetros apropiados
Los recursos están registrados para la documentación de ayuda.
Cuando se llama a una herramienta, se ejecuta el comando CLI de Salesforce correspondiente
Para los comandos que requieren un contexto de proyecto de Salesforce:
El servidor verifica si se han configurado raíces de proyecto a través de sf_set_project_directory
Si se configuran varias raíces, se utiliza la raíz predeterminada a menos que se especifique una raíz específica
Si no se establecen raíces, el servidor solicitará al usuario que especifique un directorio de proyecto.
Los comandos se ejecutan dentro del directorio del proyecto apropiado, lo que garantiza el contexto adecuado.
El usuario puede agregar o cambiar entre múltiples raíces de proyecto según sea necesario
Los comandos específicos del proyecto (como implementaciones, recuperaciones, etc.) se ejecutarán automáticamente en el directorio del proyecto correspondiente. Para los comandos que no requieren contexto de proyecto, el directorio de trabajo no importa.
Puede ejecutar comandos en raíces de proyectos específicos mediante:
Usando la URI del recurso: sf://roots/{rootName}/commands/{command}
Proporcionar un parámetro rootName a las herramientas de comando (detalles de implementación interna)
Establecer una raíz específica como predeterminada con sf_set_project_directory --isDefault=true
Para mejorar el rendimiento de inicio, el servidor MCP almacena en caché los comandos descubiertos:
El caché se almacena en ~/.sf-mcp/command-cache.json
Incluye todos los temas, comandos, parámetros y descripciones.
El caché tiene una marca de tiempo de validación y una verificación de versión de SF CLI
De forma predeterminada, la caché caduca después de 7 días.
Cuando instale nuevos complementos de Salesforce CLI, utilice sf_cache_refresh para actualizar la caché
La primera ejecución del servidor realiza un descubrimiento completo de comandos, lo cual puede tardar un tiempo. Si encuentra algún problema con comandos faltantes o problemas de caché:
Detener el servidor MCP (si está en ejecución)
Eliminar manualmente el archivo de caché: rm ~/.sf-mcp/command-cache.json
Inicie el servidor nuevamente: npm start
Esto forzará un redescubrimiento completo de todos los comandos utilizando los metadatos oficiales de la CLI.
Si aún faltan comandos específicos o ha instalado nuevos complementos de SF CLI:
Utilice la herramienta sf_cache_refresh de Claude Desktop
Detener y reiniciar el servidor MCP
La CLI de Salesforce tiene una estructura de comandos jerárquica que puede tener varios niveles de profundidad. Este servidor MCP gestiona estos comandos anidados mediante:
Conversión de rutas separadas por dos puntos al formato de guión bajo ( apex:log:get → sf_apex_log_get )
Proporcionar alias para comandos profundos comunes cuando sea posible ( sf_get para sf_apex_log_get )
Preservación de la jerarquía de comandos completa en los nombres de las herramientas
Usando la estructura de comando oficial de sf commands --json
Los comandos de temas anidados se registran dos veces cuando es posible: una vez con el nombre de la jerarquía completa y otra con un alias simplificado, lo que hace que sean más fáciles de descubrir y usar.
ISC
Clear the cached SF command metadata to force a refresh
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of behavioral disclosure. It indicates a mutation action ('Clear') that likely affects system state, but does not detail permissions, side effects, or error handling. It adds value by specifying the purpose (force refresh) but lacks depth on behavioral traits like reversibility or impact.
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 action and outcome with no wasted words. It is front-loaded and appropriately sized for a simple tool, making it easy to understand quickly.
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 complexity (simple mutation with no parameters) and lack of annotations or output schema, the description is minimally adequate. It explains what the tool does but does not cover behavioral aspects like effects or usage context in depth. For a mutation tool, more disclosure would be beneficial, but it meets basic requirements.
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 input schema has 0 parameters with 100% coverage, so no parameter documentation is needed. The description does not add parameter details, which is appropriate. Baseline is 4 for zero parameters, as the description focuses on tool purpose without unnecessary parameter repetition.
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 ('Clear') and the target ('cached SF command metadata'), with the specific outcome of forcing a refresh. It distinguishes from siblings like sf_cache_refresh by emphasizing clearing rather than refreshing, though the distinction could be more explicit. No tautology or vagueness is present.
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 implies usage when a refresh of metadata is needed, but does not explicitly state when to use this tool versus alternatives like sf_cache_refresh or other siblings. It provides some context (force a refresh) but lacks explicit guidance on prerequisites, exclusions, or comparisons with other tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Refresh the SF command cache by re-scanning all available commands
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 refreshes the cache by re-scanning commands, implying a read/write operation that updates cache state, but doesn't specify permissions needed, side effects, performance impact, or error handling. For a tool that likely modifies cache data, this is insufficient behavioral context.
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 action without unnecessary words. It is front-loaded with the core purpose ('Refresh the SF command cache') and adds clarifying detail ('by re-scanning all available commands'). Every part of the sentence contributes meaning, making it highly concise and well-structured.
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 has no parameters, no annotations, and no output schema, the description is minimal. While it states what the tool does, it lacks context about why or when to use it, behavioral traits like side effects or performance, and what the output might be. For a cache operation tool, this leaves significant gaps in understanding its role and impact.
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 tool has 0 parameters, and schema description coverage is 100% (as there are no parameters to describe). The description doesn't need to add parameter semantics, so it meets the baseline of 4 for zero-parameter tools. No additional value is required beyond stating the tool's purpose.
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 ('Refresh') and resource ('SF command cache'), and specifies the action ('by re-scanning all available commands'). It distinguishes from sibling 'sf_cache_clear' by indicating a refresh rather than a clear operation. However, it doesn't explicitly differentiate from other siblings like project directory tools, keeping it at 4 rather than 5.
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 like 'sf_cache_clear' or other cache-related operations. It lacks context about prerequisites, timing, or scenarios where this refresh is necessary versus other actions. This leaves the agent without usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get instructions for setting up Salesforce project directories for command execution
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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. It states the tool 'Get instructions,' implying a read-only operation that returns guidance, but it doesn't clarify if this requires specific permissions, what format the instructions are in, or if there are any side effects. For a tool with zero annotation coverage, this leaves significant behavioral gaps.
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, clear sentence: 'Get instructions for setting up Salesforce project directories for command execution.' It is front-loaded with the main purpose, has no unnecessary words, and efficiently conveys the tool's intent without waste.
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 has 0 parameters, no annotations, and no output schema, the description is minimally adequate. It states what the tool does but lacks details on the instruction format, prerequisites, or how it relates to sibling tools. For a tool that likely provides setup guidance, more context on the output or usage scenarios would improve completeness.
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 tool has 0 parameters, and schema description coverage is 100%, so there are no parameters to document. The description doesn't need to add parameter semantics beyond what the schema provides. A baseline score of 4 is appropriate as the description doesn't introduce confusion about parameters.
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: 'Get instructions for setting up Salesforce project directories for command execution.' It specifies the action ('Get instructions') and resource ('Salesforce project directories'), though it doesn't explicitly distinguish it from sibling tools like sf_set_project_directory. The purpose is clear but lacks 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?
The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing, or relationships with sibling tools such as sf_set_project_directory (which might actually set the directory) or sf_list_roots (which might list available directories). Without such context, the agent lacks clear usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured Salesforce project directories and their metadata
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 what the tool does but doesn't cover important aspects like whether it's read-only, requires authentication, has rate limits, or what the output format looks like. This leaves significant gaps in understanding the tool's behavior.
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 any unnecessary words. It's appropriately sized and front-loaded, making it easy for an agent to parse quickly.
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 has no parameters and no output schema, the description provides basic purpose information but lacks important context about behavior, output format, and usage guidelines. For a tool with no annotations and no output schema, more completeness would be expected to help the agent understand what to expect from the 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?
The tool has 0 parameters with 100% schema description coverage, so the schema already fully documents the input requirements. The description appropriately doesn't add parameter information beyond what's in the schema, maintaining a baseline score of 4 for tools with no parameters.
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 ('List') and the resource ('all configured Salesforce project directories and their metadata'), providing a specific verb+resource combination. However, it doesn't explicitly differentiate from sibling tools like sf_detect_project_directory or sf_set_project_directory, 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. There's no mention of prerequisites, timing, or comparison to siblings like sf_cache_clear or sf_detect_project_directory, leaving the agent without contextual usage instructions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Set a Salesforce project directory for command execution context
| Name | Required | Description | Default |
|---|---|---|---|
| directory | Yes | The absolute path to a directory containing an sfdx-project.json file | |
| name | No | Optional name for this project root | |
| description | No | Optional description for this project root | |
| isDefault | No | Set this root as the default for command execution |
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 mentions setting a directory for 'command execution context,' which implies configuration/mutation, but doesn't specify whether this persists across sessions, requires specific permissions, or has side effects. For a mutation tool with zero annotation coverage, this is a significant gap in transparency.
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, clear sentence that directly states the tool's purpose without unnecessary words. It's front-loaded and efficient, making it easy for an agent to parse quickly.
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 has 4 parameters, no annotations, and no output schema, the description is minimally adequate but incomplete. It covers the basic purpose but lacks details on behavioral traits, usage context, and output expectations, which are crucial for a mutation tool in a set of related Salesforce commands.
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%, meaning all parameters are documented in the schema itself. The description adds no additional semantic information about parameters beyond what's in the schema, such as usage examples or constraints. This meets the baseline for high schema coverage but doesn't provide extra value.
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 ('Set') and the resource ('Salesforce project directory for command execution context'), making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like sf_detect_project_directory or sf_list_roots, 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. There's no mention of prerequisites (e.g., needing an sfdx-project.json file), when not to use it, or how it relates to sibling tools like sf_detect_project_directory. This leaves the agent with minimal context for tool selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0sf_cache_clear1 field changedInput schema / additionalPropertiesRemoved value: -falsesf_cache_refresh1 field changedInput schema / additionalPropertiesRemoved value: -falsesf_detect_project_directory1 field changedInput schema / additionalPropertiesRemoved value: -falsesf_list_roots1 field changedInput schema / additionalPropertiesRemoved value: -falsesf_cache_clearsf_cache_refreshsf_detect_project_directorysf_list_rootssf_set_project_directoryScored across 5 tools
Each tool has a clearly distinct purpose with no overlap: cache_clear and cache_refresh handle metadata caching, detect_project_directory provides setup instructions, list_roots enumerates existing directories, and set_project_directory establishes execution context. The descriptions reinforce these boundaries, making misselection unlikely.
All tools follow a consistent 'sf_verb_noun' pattern with snake_case throughout (e.g., sf_cache_clear, sf_detect_project_directory). This predictable naming scheme makes the tool set easy to navigate and understand at a glance.
Five tools is reasonable for a Salesforce CLI server focused on project directory management and cache operations. It's slightly lean but covers core setup and maintenance tasks without feeling bloated or incomplete for its apparent scope.
The tool set covers project directory setup, listing, and context setting, plus cache management, but lacks direct Salesforce CLI command execution tools (e.g., running queries or deploying metadata). This creates a notable gap for agents needing to perform actual Salesforce operations, though the provided tools support preparatory workflows.
Plan Salesforce deploys, open pull requests and trigger pipelines from your AI client.
Provides capabilities that let LLM agents perform a range of infrastructure management tasks.
Run SOQL queries to explore and retrieve Salesforce data. Access accounts, contacts, opportunities…
Operate Linux, macOS and Windows from your LLM. Every action runs through an auditable allowlist.
