The Salesforce MCP server, verified live on a real Mac.

Intelligently determines the appropriate username or alias for Salesforce operations. WHEN TO USE THIS TOOL: - When uncertain which org username a user wants for Salesforce operations. To resolve the default org username, set the defaultTargetOrg param to true and defaultDevHub to false. To resole the default devhub org username, set the defaultTargetOrg param to false and defaultDevHub to true. If it's not clear which type of org to resolve, set both defaultTargetOrg and defaultDevHub to false to an allow-listed org username available.

Resume a long running operation that was not completed by another tool. AGENT INSTRUCTIONS: Use this tool to resume a long running operation. EXAMPLE USAGE: Resume the metadata deploy job 0Af1234567890 Resume the deployment and wait for 10 minutes Resume the deployment to my org Resume scratch org creation Resume job 2SR1234567890 Resume agent tests Resume org snapshot with ID 0OoKa000000XZAbKAO Report on my org snapshot

Run a SOQL query against a Salesforce org.

Lists all configured Salesforce orgs. AGENT INSTRUCTIONS: DO NOT use this tool to try to determine which org a user wants, use #get_username instead. Only use it if the user explicitly asks for a list of orgs. Example usage: Can you list all Salesforce orgs for me List all Salesforce orgs List all orgs

Deploy metadata to an org from your local project. AGENT INSTRUCTIONS: If the user doesn't specify what to deploy exactly ("deploy my changes"), leave the "sourceDir", "ignoreConflicts" and "manifest" params empty so the tool calculates which files to deploy. EXAMPLE USAGE: Deploy changes to my org Deploy this file to my org Deploy the manifest Deploy X metadata to my org Deploy X local files to my org and ignore any conflicts between the local project and org Deploy X to my org and run A,B and C apex tests.

Retrieve metadata from an org to your local project. AGENT INSTRUCTIONS: If the user doesn't specify what to retrieve exactly ("retrieve my changes"), leave the "sourceDir", "ignoreConflicts", and "manifest" params empty so the tool calculates which files to retrieve. EXAMPLE USAGE: Retrieve changes Retrieve changes from my org Retrieve this file from my org Retrieve the metadata in the manifest Retrieve X metadata from my org Retrieve X metadata from my org and ignore any conflicts between the local project and org

Run Agent tests in an org. AGENT INSTRUCTIONS: If the user doesn't specify what to test, take context from the currently open file This will ONLY run Agent tests, NOT apex tests, lightning tests, flow tests, or any other type of test. this should be chosen when a file in the 'aiEvaluationDefinitions' directory is mentioned EXAMPLE USAGE: Run tests for the X agent Run this test start myAgentTest and don't wait for results

Run Apex tests in an org. AGENT INSTRUCTIONS: If the user doesn't specify what to test, take context from the currently open file This will ONLY run APEX tests, NOT agent tests, lightning tests, flow tests, or any other type of test. this should be chosen when a file in the 'classes' directory is mentioned EXAMPLE USAGE: Run tests A, B, C. Run the myTestMethod in this file Run this test and include success and failures Run all tests in the org. Test the "mySuite" suite asynchronously. I’ll check results later. Run tests for this file and include coverage What are the results for 707XXXXXXXXXXXX

Assign a permission set to one or more org users.

Analyzes LWC components for mobile-specific issues and provides detailed recommendations for improvements. It can be leveraged to check if components are mobile-ready.

Provides structured review instructions to detect and remediate Mobile Offline code violations in Lightning web components (LWCs) for Salesforce Mobile Apps.

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC App Review Service, laying the foundation for understanding mobile app review and offering expert-level guidance for implementing the App Review feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC AR Space Capture, laying the foundation for understanding mobile AR space capture and offering expert-level guidance for implementing the AR Space Capture feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Barcode Scanner, laying the foundation for understanding mobile barcode scanner and offering expert-level guidance for implementing the Barcode Scanner feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Biometrics Service, laying the foundation for understanding mobile biometrics and offering expert-level guidance for implementing the Biometrics feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Calendar Service, laying the foundation for understanding mobile calendar and offering expert-level guidance for implementing the Calendar feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Contacts Service, laying the foundation for understanding mobile contacts and offering expert-level guidance for implementing the Contacts feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Document Scanner, laying the foundation for understanding mobile document scanner and offering expert-level guidance for implementing the Document Scanner feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Geofencing Service, laying the foundation for understanding mobile geofencing and offering expert-level guidance for implementing the Geofencing feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Location Service, laying the foundation for understanding mobile location and offering expert-level guidance for implementing the Location feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC NFC Service, laying the foundation for understanding mobile NFC and offering expert-level guidance for implementing the NFC feature in a Lightning Web Component (LWC).

The MCP tool provides a comprehensive TypeScript-based API documentation for Salesforce LWC Payments Service, laying the foundation for understanding mobile payments and offering expert-level guidance for implementing the Payments feature in a Lightning Web Component (LWC).

Use this tool to generate a Product Requirements Document (PRD) from a Salesforce Aura component. The PRD outlines the component's structure, functionality, and requirements for migrating or converting it into a Lightning Web Component (LWC), as part of the Aura to LWC migration workflow orchestrator.

Use this tool to enhance a draft Product Requirements Document (PRD) as part of the Aura to LWC migration workflow orchestrator.

Use this tool to provide next-step migration instructions from a Product Requirements Document (PRD) to a Lightning Web Component (LWC), as part of the Aura to LWC migration workflow orchestrator. The PRD is generated from a Salesforce Aura component.

Use this tool to orchestrate a workflow to convert or migrate a Salesforce Aura component into its Lightning Web Component (LWC) equivalent. The input can be either an Aura component bundle file (e.g., .cmp, .controller.js, .helper.js, etc.) or a directory containing Aura component bundle files.

Completeness Checklist for aura to LWC conversion using this tool.

Prior to generating an LWC component from a Figma design, you must call this tool to understand how to do this for salesforce.

Use this tool to create a Lightning Web Component (LWC) from a Product Requirement Document (PRD).

This is a sub tool of the orchestrate_lwc_component_testing. It should only be used as part of the workflow, not directly. Performs comprehensive component analysis and generates test suite using a static knowledge base.

Provides accessibility guidelines. When hasImages=true, includes Vision AI accessibility guidelines. Use this tool for both code-based accessibility guidance and visual accessibility validation.

Use this tool for Salesforce LWC best practices guidelines for Lightning Web Component (LWC).

Use this tool to get guidance on Lightning Web Components (LWC) development.

This is a sub tool of the orchestrate_lwc_component_testing. It should only be used as part of the workflow, not directly. Reviews test coverage and implementation based on initial analysis. Only provides feedback and recommendations, never generates or rewrites test code.

Use this tool to create a LWC Components (Lightning Web Components) by orchestrating a workflow that provides step-by-step guidelines

Use this tool to orchestrate a workflow that provides step-by-step guidance for optimization of a Lightning Web Component (LWC)

Use this tool to orchestrate a workflow that will comprehensively generate or enhance and validate Jest unit tests for a Lightning Web Component (LWC)

Use this tool to explore Lightning Data Service (LDS) UI API documentation, browse available adapter APIs, and retrieve type definitions for LWC development. Use this when you need to discover what LDS APIs are available or get specific API documentation.

Use this tool to get detailed guidance on implementing data consistency patterns in LWC components when working with Salesforce record data through Lightning Data Service (LDS).

Use this tool to get comprehensive Lightning Data Service (LDS) guidelines covering data consistency, referential integrity, and choosing UIAPI vs Apex, with review checklists and links to specialized knowledge tools. Start here for general LDS guidance, then use specialized tools for deeper dives.

Use this tool to get detailed guidance on implementing referential integrity best practices in LWC components to make your code resilient against object/field name changes. Use this when you need to review Salesforce Record data access.

Provides detailed instructions and commands for running Sa11y accessibility Jest tests on LWC components. Covers both Bazel commands (core build environment) and Jest commands (standalone environment).

Use this tool to get comprehensive security analysis in accordance with Product Security Guidelines and Lightning Web Security Guidelines. Use this to identify and fix security vulnerabilities in your code.

Provides step-by-step workflow guidance for analyzing and clarifying LDS data requirements to produce PRD-ready specifications.

Use this tool to get detailed guidance on implementing GraphQL patterns in LWC components when working with Salesforce data through Lightning Data Service (LDS) GraphQL APIs.

This is a sub tool of the guide_lds_graphql tool. It **must** only be called as part of its workflow, not directly. Use this tool to create GraphQL read queries for Lightning Web Components using Salesforce Lightning Data Service (LDS) GraphQL APIs.

This is a sub tool of the guide_lds_graphql tool. It **must** only be called as part of its workflow, not directly. Use this tool to create GraphQL mutation queries for Lightning Web Components using Salesforce Lightning Data Service (LDS) GraphQL APIs.

Fetches the full GraphQL introspection schema from a connected Salesforce org and saves it to the local filesystem. Returns only the file path and metadata — the schema content never enters the conversation context. Use the saved schema file path in your codegen.yml and ESLint graphql config.

This is a sub tool of the create_lds_graphql_read_query and create_lds_graphql_mutation_query tools. It **must** only be called as part of their workflows, not directly. Tests a GraphQL query against a connected Salesforce org and returns the result.

Provides comprehensive Salesforce Lightning Design System (SLDS) guidelines and best practices for creating enterprise Lightning Web Components with proper accessibility, responsive design, and component usage patterns.

(Developer Preview) Creates, enhances, and provides expert guidance and best practices for custom Lightning types. Generates and maintains LightningTypeBundle components, including schema.json, editor.json, renderer.json, and validation rules, for use across Salesforce applications.

Use this tool to discover which Lightning Base Components are available and find the best fit for a given use case. Follow the returned instructions to identify candidates, then call explore_lbc_components to retrieve their full API documentation.

Use this tool to retrieve full API documentation for specific Lightning Base Components by name. Returns properties, methods, events, slots, and usage notes. Use guide_lbc_usage first to identify which component names to pass here.

Look up documentation for a single LWC compilation error code (e.g., "LWC1034"). Returns the error description, root cause, examples, and suggested fix steps from the knowledge base. Call this tool once per error code. PREREQUISITES (must be completed BEFORE calling this tool): 1. The error code MUST come from actual compiler output or IDE diagnostics. If you do not have compiler output, compile the component first or ask the user for the error codes shown in their IDE. NEVER guess or infer error codes from reading the source code. 2. Read ALL component files (JS, HTML, CSS) for the affected component.

Migration recipe: converts a Lightning Out (beta) host page into a Lightning Out 2.0 host page. Includes LO 2.0 architecture reference, step-by-step instructions, value mapping table, and a complete page skeleton with placeholders.

List all DevOps Center projects in a specific org **Terminology:** Treat "DevOps Center", "DOCe", and "DoCe" as the same product/org context. **MANDATORY:** If the DevOps Center org is not given, use the 'list_all_orgs' tool to list all orgs. The list will indicate which org is DevOps Center, or Sandbox if possible. If these details are not provided in the list, ask the user to specify which org is DevOps Center org. Only proceed after the user has selected the DevOps Center org. **MANDATORY:** Before using this tool, always confirm the selected org is the DevOps Center org. If not, prompt the user to select a DevOps Center org. This tool must NOT be used for any non DevOps Center or Sandbox orgs. **Input:** - Either username (example devops-center@example.com) or alias (example myDevOpsOrg) is required. Lists DevOps Center Projects available in the specified org using SOQL on DevopsProject. **Output:** An array of project records with fields such as Id, Name, Description.

List all the work items for a specific DevOps Center project. **Terminology:** Treat "DevOps Center", "DOCe", and "DoCe" as the same product/org context. **Input:** - Either username (example devops-center@example.com) or alias (example myDevOpsOrg) is required. **MANDATORY:** If the DevOps Center org is not given, use the 'sf-list-all-orgs' tool to list all orgs. The list will indicate which org is DevOps Center, or Sandbox if possible. If these details are not provided in the list, ask the user to specify which org is DevOps Center org. Only proceed after the user has selected the DevOps Center org. **MANDATORY:** Before using this tool, always confirm the selected org is the DevOps Center org. If not, prompt the user to select a DevOps Center org. This tool must NOT be used for any non DevOps Center or Sandbox orgs. **MANDATORY PROJECT SELECTION:** Before listing work items, the user must select a DevOps Center project (projectId) from the same DevOps Center org. First call 'list_devops_center_projects' for that org, then pass the selected project's Id here. The org used here must match the org used to fetch the projects. Lists work items from a Salesforce DevOps Center project. Each work item includes branch, environment, and repository details needed for checkout and promotion. **After using this tool, always suggest the user with the next actions:** **LLM should strictly suggest only these two options:** 1. Start work on the work item (use the 'checkout_devops_center_work_item' tool) 2. Promote work items (use the 'promote_devops_center_work_item' tool)

Creates a new DevOps Center Work Item in the specified project. **Usage notes:** - This tool must be used for the DevOps Center org only. If the org is not provided, use 'list_all_orgs' to select the DevOps Center org. - A DevOps Center project must be selected first from the same org. If the projectId is not known, call 'list_devops_center_projects' for that org and ask the user to select a project. Use that project's Id here. - Ensure the org used to select the project is the same org passed to this tool. - **(Mandatory)** Always ask the user to give the work item subject. Don't proceed until the user has provided the subject. **(Mandatory)** **API:** POST /services/data/v65.0/connect/devops/projects/<ProjectID>/workitem **Body:** { "subject": string, "description": string } **Input parameters:** - usernameOrAlias: DevOps Center org username or alias. If missing, use 'list_all_orgs' and ask user to select the DevOps Center org. - projectId: DevOps Center Project ID from list_devops_center_projects for the same org. - subject: Work item subject. - description: Work item description (optional). **Output:** - success: Whether the create succeeded. - workItemId, workItemName, subject: Created work item details on success. - error: Error message if the create failed.

Promote an approved work item to the next stage in the DevOps Center pipeline. **Use when user asks (examples):** - "Promote WI-123 to UAT" - "Promote my approved work item" - "Release WI-456 to next stage" **Prerequisites:** - This tool must be used only for the DevOps Center org. - The user must provide: username (DevOps Center) and a list of Work Item Names. **Input Parameters:** - username: DevOps Center org username. If missing, use 'list_all_orgs' and ask user to select the DevOps Center org. - workItemNames: Array of exact Work Item Names to promote. **Behavior:** 1. Fetches the specified Work Items by Name and derives PipelineId and TargetStageId automatically. 2. Validates that each Work Item has PipelineStageId and a resolvable TargetStageId. 3. Calls the promotion API with the resolved ids. **Safety and guidance for the LLM:** - Do not auto-select a non-DevOps Center org; always confirm with the user. - If any Work Item is not found or missing required pipeline data, return an actionable error listing which names failed. - Never promote without explicit user confirmation of workitems. **Output:** - JSON with promotion requestId (if available) and any error details. **Next steps:** - Suggest how to track promotion status using the returned requestId or the DevOps Center UI. - If applicable, prompt the user to promote to the next stage after validation. **Output:** A JSON object containing the promotion request ID, the org details, and any relevant status or tracking information.

Detects merge conflicts for a selected work item or in given source branch. **When to use:** - User asks to detect conflicts for a work item, or asks for help fixing a merge conflict. - User asks to detect conflicts for a given source branch. **MANDATORY input:** - Either workitem name (example WI-0000000X) or source branch (example WI-0000000X) is provided. - usernameOrAlias: DevOps Center org username or alias (example devops-center-org). **Behavior:** - The tool will look up the Work Item by Name in the DevOps Center org and compute target branch automatically. - If the item cannot be found, or required fields are missing (branch or repo), it will return actionable guidance. **What this tool does:** 1. Validates required properties (WorkItemBranch, TargetBranch, SourceCodeRepository.repoUrl) 2. Provides instructions to check for conflicts between the work item branch and target branch 3. Runs the necessary git commands to detect conflicts and surface findings **Output:** - If conflicts exist: lists conflicted files and suggested next steps - If no conflicts: confirms it is safe to merge - On error: returns details **Next step:** - After detection, call 'resolve_devops_center_merge_conflict' to guide the user through conflict resolution.

Guides merge conflict resolution for a selected work item by name. **When to use:** - After running 'detect_devops_center_merge_conflict' and conflicts were found. **MANDATORY input:** - workItemName (exact Name of the Work Item) and username or alias of the DevOps Center org. **Behavior:** - Looks up the Work Item by Name, validates required fields, and prepares per-file resolution commands. - If branch/target branch/repo URL are missing, returns actionable guidance to fix inputs first. - NEVER auto-resolve conflicts. For every conflicted file, the agent must ask the user which side to keep and wait for explicit confirmation before running any checkout command. **What this tool does:** 1. Confirms the repo is in a conflicted state 2. Lists conflicted files 3. For each file, asks the user to choose one option only: keep current OR keep incoming 4. After each explicit user choice, applies the selected command and stages the file 5. Verifies conflicts are cleared and guides local commit steps **Hard constraints:** - Do not run `git checkout --ours` or `git checkout --theirs` until the user chooses for that specific file. - Do not offer or attempt a "keep both" merge path in this tool. - Keep operations local unless the user explicitly asks to push. **Output:** - If conflicts exist: per-file action plan with commands - If no conflicts: confirms the repo is clean - On error: actionable troubleshooting

Determine if **full promotion** can fix a deployment failure and guide the user. **Inputs:** workItemName (mandatory), sourceBranchName (mandatory), errorDetails (mandatory), localPath (optional; defaults to current working directory), targetBranchName (optional; when provided, source and target are compared to confirm if full promotion will resolve). **Behavior:** 1. **Merge conflict**: Full promotion cannot fix → instruct to use **resolve_devops_center_merge_conflict**. 2. **All other errors**: The tool **checks out the source branch** in the repo (at localPath), then parses the error for a missing dependency and checks if the **source branch** contains it. If **source contains the missing dependency** → full promotion can fix → ask for confirmation (see below), then proceed to full promotion after user confirms. If **source does not contain it** (or no dependency could be parsed) → return generic instructions to resolve the deployment failure. **MANDATORY – Ask for confirmation; do NOT run full promotion without it:** - When this tool returns that full promotion can fix the failure, you MUST present the confirmation request to the user and STOP. - Do NOT call **promote_devops_center_work_item** until the user explicitly confirms (e.g. "Yes", "Proceed", "Go ahead"). - Only after the user confirms should you call **promote_devops_center_work_item** with usernameOrAlias, workItemNames: [workItemName], isFullDeploy: true.

Checks out the branch associated with a selected work item by name. **Terminology:** Treat "DevOps Center", "DOCe", and "DoCe" as the same product/org context. **MANDATORY:** Always ask the user to provide the local path (repoPath) to the checked-out repository. You may show the current working directory as an option, but do not proceed until the user has explicitly chosen a repo path. Never assume or default to a path without user confirmation. This tool takes the DevOps Center org username and the exact Work Item Name, looks up the Work Item to retrieve its repository URL and branch, and then checks out that branch. If localPath is not provided, the current working directory will be used. It clones the repository to the specified local path if it does not exist there, and checks out the specified branch. Assumes the user is already authenticated with the git CLI. **How to use this tool:** 1. **Work Item Name Required:** - Provide the exact Work Item Name and the DevOps Center org username. The tool will fetch the Work Item and derive repo URL and branch automatically. 2. **Input Parameters:** - "username": The username of the DevOps Center org. - "workItemName": The exact Name of the Work Item whose branch to check out. - "localPath" (mandatory): The directory path where the repository should be cloned/checked out. Must be provided by the user. The current working directory can be shown as an option, but do not proceed until the user chooses. 3. **Operation:** - If the repository does not exist at the specified local path, the tool will clone it there. - The tool will then check out the specified branch in that directory. - The output will explicitly show the path where the repository is cloned. **Typical workflow:** - Provide Work Item Name and local path, then run this tool to clone and check out the correct branch. **Output:** - Success or error message indicating the result of the clone and checkout operations, including the path where the repository is cloned.

Commit SFDX project changes and register the commit SHA in DevOps Center. **CRITICAL:** Do not run git commands (git add/commit/push) manually. When a user asks to commit, call this tool so DevOps Center correctly tracks metadata and links the commit to the Work Item. **CRITICAL:** This tool commits on the currently checked out branch. Ensure current branch matches the selected Work Item branch before running. **Inputs to validate before execution:** 1. DevOps Center org identifier (username or alias) 2. Work Item Name that resolves in the org 3. Repository path pointing to the project root (git repo) 4. Non-empty commit message **Use this tool to:** - Finalize and record changes for a Work Item in DevOps Center - Commit using DevOps Center credentials and conventions - Ensure metadata changes are captured correctly in the pipeline **After execution:** - Follow the returned instructions to push (if not pushed automatically) - Then create a PR (use 'create_devops_center_pull_request') as the next step **Output:** - commitSha: The resulting commit SHA (plus push instructions if applicable) **Example:** - "Commit my changes with message 'Fix bug in account logic' and tie it to WI-1092."

Update the status of a DevOps Center work item to either "In Progress" or "Ready to Promote". **Use when user asks (examples):** - "Mark WI-123 In Progress" - "Set work item WI-456 to Ready to Promote" - "Change work item status to In Progress" - "Mark my work item as Ready to Promote" **Prerequisites:** - This tool must be used only for the DevOps Center org. - The user must provide: username (DevOps Center), Work Item Name, and the desired status. **Input Parameters:** - usernameOrAlias: DevOps Center org username or alias. If missing, use 'list_all_orgs' and ask user to select the DevOps Center org. - workItemName: Exact Work Item Name (e.g. WI-00000001). - status: New status - either "In Progress" or "Ready to Promote". **Output:** - success: Whether the update succeeded. - workItemId, workItemName, status: Updated work item details on success. - error: Error message if the work item was not found or update failed. **Next steps:** - After marking "Ready to Promote", suggest promoting the work item (using 'promote_devops_center_work_item') when appropriate.

Check the current status of a work item committed to DevOps Center. **Use this tool to:** - Check the status of a specific commit using its Request Id - Verify commit processing completion before creating a pull request - Ensure commits are ready for PR creation **Input Parameters:** - usernameOrAlias: The username or alias of the DevOps Center org to authenticate with - requestId: The specific request Id to check status for (REQUIRED) **Output:** - Status field value for the specified request Id - Request Id and associated status information

Commit local changes to a DevOps Center work item's feature branch **IMPORTANT: THIS IS NOT A STARTING TOOL** When user asks to "create pull request" or "create PR", DO NOT use this tool directly. Instead, start with step 1 below. **THIS TOOL IS ONLY USED AS THE FINAL STEP AFTER COMPLETING ALL PREREQUISITES** **MANDATORY workflow for creating pull requests: DO NOT skip any of the steps and DO NOT move to the next step until the current step is completed.** 1. **MANDATORY:** If the DevOps Center org is not given, use the 'list_all_orgs' tool to list all orgs. The list will indicate which org is DevOps Center. If this detail is not provided in the list, then ask the user to specify which org is DevOps Center. Only proceed after the user has selected the DevOps Center org. 2. **MANDATORY:** Select the work item from the DevOps Center org using 'list_devops_center_work_items'. 3. **MANDATORY:** Checkout the work item branch using 'checkout_devops_center_work_item' to get the project code locally. 4. **MANDATORY:** Verify with the user that all changes have been manually committed and pushed to the work item branch. DO NOT use any commit tools - this should be done manually by the user. 5. **MANDATORY - PREREQUISITE CHECK:** Ask the user for their commit request ID and use the 'check_devops_center_commit_status' tool to verify the status of their previous commits. You MUST call 'check_devops_center_commit_status' before proceeding. Do not skip this step. 6. **MANDATORY:** Only after successfully verifying commit status with 'check_devops_center_commit_status', call this tool to create the pull request using the DevOps Center API. **Use this tool to:** - Create a Pull Request based on a work item in DevOps Center - Initiate the review process for completed work items - Move work items from development to review stage **After using this tool, suggest these next actions:** 1. Ask the user to review the created pull request using the returned reviewUrl 2. Ask the user to promote work items (using the 'promote_devops_center_work_item' tool) after PR approval **Output:** - reviewUrl: URL where the user can check the created pull request - status: Status of the pull request creation - workItemId: The work item ID for reference - errorMessage: Error message if the pull request creation failed **Example Usage:** - "Create a pull request for Work Item and merge it into integration" - "Open a PR from my current feature branch to the integration branch" - "Create and register a PR to DevOps Center from my latest pushed commits" - "Create a change request for my committed changes" - "Start the review process for my work item"

A tool for performing static analysis against code. This tool can validate that code conforms to best practices, check for security vulnerabilities, and identify possible performance issues. It returns a JSON containing the absolute path to a results file if such a file was created, and a string indicating the overall success or failure of the operation. When to use this tool: - When the user asks you to generate files, use this tool to scan those files. - When the user asks you to check code for problems, use this tool to do that. REQUIRED INPUT - Directory: - You MUST provide the "directory" parameter with the absolute path to the project/workspace root. - The tool will automatically search for code-analyzer.yml or code-analyzer.yaml config files in this directory. - Config files contain custom rule configurations, severities, and ignore patterns that will be respected. - If no config file is found in the directory, default configuration will be used. OPTIONAL - Custom Config Path: - Use "configPath" parameter only if the config file has a custom name or is in a non-standard location. - If provided, configPath takes precedence over config files in directory. Optional: Provide a "selector" to choose which rules to run. Supports: - Rule names: "WhileLoopsMustUseBraces", "no-unused-vars" - Engines: "pmd", "eslint", "regex" - Tags: "Security", "Performance", "Recommended" - Severities: "Critical", "High", "1", "2" - Combinations: "Security:pmd", "(Security,Performance):eslint" Examples: - "WhileLoopsMustUseBraces" → run specific rule by name - "Security:pmd" → run Security-tagged PMD rules - "Critical" → run all Critical-severity rules - "(Security,Performance):eslint" → ESLint rules tagged Security or Performance After completion: Use the "query_code_analyzer_results" tool to filter and explain results, e.g., top-N most severe violations or violations by category/tag.

A tool for getting the description of a Code Analyzer rule. This tool can return a JSON that describes the properties of a Code Analyzer rule, which may include information about how it can be fixed. When to use this tool: - When the results file from the run_code_analyzer tool does not provide enough information to fix a violation yourself. - When the user asks for information about a specific rule or violation.

A tool for selecting Code Analyzer rules based on a number of criteria. This tool returns a JSON array describing Code Analyzer rules that match a "selector". A selector is a colon-separated (:) string of tokens; tags and severity names are case-insensitive. You can OR multiple tokens of the same type by grouping them in parentheses and separating with commas, e.g. "(Performance,Security)". Policy: To prevent overly broad results, the full unfiltered list of rules is not returned unless you explicitly set allowFullList=true. This flag defaults to false and its use is not recommended. Note: Listing large rule sets can significantly increase token consumption. Examples: - "Recommended" → all rules tagged as Recommended. - "Performance:pmd:Critical" → rules in the PMD engine with the Performance tag and Critical severity. - "pmd:(Performance,Security):2" → PMD rules with Performance OR Security tags and severity 2. - "(Apex,JavaScript):Recommended" → rules for Apex OR JavaScript languages that are Recommended. - "Security:High" → rules tagged Security with High severity. - "Apex:Recommended" → rules for the Apex language that are Recommended. - "DevPreview" → rules marked as DevPreview. - Prompt: "tell me about all performance rules" → selector: "Performance". Supported selector tokens: - Engines: eslint, regex, retire-js, flow, pmd, cpd, sfge - Severities (names): Critical, High, Moderate, Low, Info - Severities (numbers): 1, 2, 3, 4, 5 - General tags: Recommended, Custom, All - Categories: BestPractices, CodeStyle, Design, Documentation, ErrorProne, Security, Performance - Languages: Apex, CSS, HTML, JavaScript, TypeScript, Visualforce, XML - Engine-specific tags: DevPreview, LWC Tip: Use the "describe_code_analyzer_rule" tool to get details for any listed rule.

Query a Code Analyzer results JSON file and return filtered violations. Supports filters like severity, category/tag, engine, rule, and file name, plus top-N and sorting. Use this after running "run_code_analyzer" to read the generated results file. After completion, this tool will summarize and explain the filtered results to the user. Policy: To avoid overwhelming results, this tool returns no more than the top 10 violations by default. Requesting more than 10 requires an explicit opt-in via allowLargeResultSet=true and is not recommended. Note: Querying larger result sets can significantly increase token consumption. Examples (natural language → selector/topN): - "Top 5 security in PMD" → selector: "Security:pmd", topN: 5 - "Top 10 critical" → selector: "Critical", topN: 10 - "Top 5 security or performance in ESLint" → selector: "(Security,Performance):eslint", topN: 5 - "Top 5 PMD High severity" → selector: "pmd:High", topN: 5 - "Top 5 for rule MyRuleName" → selector: "rule=MyRuleName", topN: 5 - "Top 5 in files under src/app" → selector: "file=src/app", topN: 5

Apex Code Scan Tool: Invoke (alongside other code scan tools if needed) whenever the user intends to scan or analyze an Apex class. Analyzes an Apex class file for performance antipatterns and provides recommendations for fixing them. Currently detects: 1) Schema.getGlobalDescribe() usage with optimized alternatives 2) SOQL queries without WHERE or LIMIT clauses 3) SOQL queries with unused fields (with fix generation). Distinguishes between different severity levels (e.g., usage in loops vs. ordinary usage). When authenticated to an org with ApexGuru enabled, severity is calculated from actual runtime metrics. IMPORTANT: If the user does not mention an org alias or username in the request, call #get_username tool to resolve the default org username. Requires an absolute path to the Apex class file.

Validation tool for UI component quality assessment. This tool returns a runbook that instructs the agent to: - Call a list of validators (predefined suite OR a custom list supplied by the caller) - Produce issues per validator - Call `score_issues` after each validator and again for the overall score - Stop and present results before fixing/revalidating Provide EITHER `suite` (a predefined validator set) OR `validators` (an explicit list), but not both.

Score validation issues using readiness scoring rules. ## WHEN TO USE THIS TOOL Use this tool when you need a numeric score + quality grade from a set of issues: - After a single validator run (per-validator score) - After aggregating issues across validators (overall readiness score) ## Input Provide one or more of these (all are merged before scoring): - `issues`: A SARIF 2.1.0 report. - `codeAnalyzerResultsFiles`: Array of file paths to code analyzer JSON results. The tool reads and converts them internally — preferred to avoid wasting tokens. - `codeAnalyzerResults`: Array of inline code analyzer result objects (fallback if file reading fails). If all inputs are omitted, scores as zero issues. ## Output Returns: - `readinessScore`: number (0-100) - `qualityGrade`: 'draft' | 'prototype' | 'review-for-production' - `breakdown`: counts + penalty - `sarif`: (only when `codeAnalyzerResultsFiles` was provided) the combined SARIF report so you have the full issue details for summary and fixing ## Aggregate Mode Instead of re-submitting all issues, you can pass pre-computed per-validator scores: - `validatorScores`: Array of `{ name, score }` from individual per-validator calls. - Returns the weighted aggregate score using per-validator weights. - **Mutually exclusive** with `issues`, `codeAnalyzerResultsFiles`, and `codeAnalyzerResults`.