Use the LWC Development MCP Tools (Beta)

The LWC development MCP tools speed up component creation from PRD specifications and facilitate with various aspects of LWC development.

MCP Tools for LWC is a pilot or beta service that is subject to the Beta Services Terms at Agreements - Salesforce.com or a written Unified Pilot Agreement if executed by Customer, and applicable terms in the Product Terms Directory. Use of this pilot or beta service is at the Customer's sole discretion.
  • guide_lwc_development - Comprehensive LWC development workflow and implementation guidelines
  • guide_lwc_best_practices - Offers LWC development best practices and coding standards guidance
  • create_lwc_component_from_prd - Creates LWC components from PRD specifications with proper structure and best practices
  • orchestrate_lwc_component_creation - Step-by-step component creation workflow guidance
  • orchestrate_lwc_component_optimization - Performance optimization and best practices for LWC
  • guide_lwc_accessibility - Provides accessibility guidelines and testing instructions for Lightning web components
  • guide_lwc_rtl_support - Right-to-Left (RTL) internationalization support and RTL development guidance
  • guide_lwc_slds2_uplift_linter_fixes - Analyzes LWC code along with the slds-linter output to fix issues using the SLDS 2 knowledge
  • orchestrate_lwc_slds2_uplift - Migration guidance for upgrading to SLDS 2

When working with these tools using Agentforce Vibes Extension, you must enable the a4d-general-rules-no-edit.md and a4d-lwc-rules-no-edit.md global rules. The a4d-general-rules-no-edit.md rule is enabled by default. For more information on configuring rules in Agentforce Vibes, see Agentforce Rules in the Agentforce Vibes Extension Developer Guide.

Here are some sample prompts that invoke the LWC development MCP tools.

Ask about evaluating a component based on development workflow guidelines.

  • Outline the end-to-end workflow to build a list of case records with UI API, including error states.
  • Provide a development checklist for this component in these areas: data, events, a11y, tests, performance.
  • Compare when to use UI API vs Apex for a record update and recommend an approach.

Ask about reviewing a component based on LWC best practices.

  • Review this component for LWC best practices and suggest improvements.
  • Recommend patterns for state management and eventing for this component.
  • Identify anti-patterns in this code and propose compliant alternatives.

Ask about creating a component based on a PRD.

  • Create an LWC component named accountList from this PRD: <paste PRD>
  • From the PRD below, generate the contactCard component. <paste PRD>
  • Generate an LWC component that that displays a list of cases using getListUi based on this PRD. <paste PRD>

Ask about guidelines on creating a component.

  • Outline step-by-step tasks to build a contact list component.
  • Recommend data access (UI API vs Apex) and eventing approach for this component.
  • Provide an a11y checklist (roles, labels, keyboard, focus) tailored to this UI.

Ask about optimizing a component and proposing performance strategies.

  • Recommend virtualization or pagination for long lists and heavy DOM updates.
  • Propose strategies to reduce wire traffic via field minimization, batching, and caching.
  • Provide a performance checklist for TTI, CPU cost, paint, and memory.

Ask about reviewing a component based on LWC accessibility guidelines.

  • Review this component for accessibility and list concrete fixes with code examples.
  • Provide a step-by-step plan to run a11y Jest tests for this component and interpret failures.
  • Generate an ARIA/keyboard checklist for this component and verify focus management.

Ask about evaluating a component based on RTL guidelines.

  • Assess this component for RTL readiness and list CSS logical property changes.
  • Provide RTL testing steps and visual checks for this component.
  • Convert these LTR styles to RTL-safe equivalents and explain choices: <paste CSS>

Ask about enhancing a component based on SLDS 2 guidelines and best practices.

  • Run SLDS 2 uplift linter on components under force-app/main/default/lwc. Group violations by rule and component and provide autofix suggestions. Include a brief rationale per rule and call out any rules requiring manual remediation.
  • Analyze this component for SLDS 2 issues. Generate a brief summary listing files changed, rules fixed, and remaining violations. Ensure no visual regressions by avoiding disruptive class removals without substitutions.
  • Identify deprecated classes and tokens for SLDS 2, and suggest compatible replacements. Map each finding to a linter rule. Output a table with columns: Rule, File Location, Problem, Recommended Fix. Provide a step-by-step fix order to minimize cascading changes.

Ask about migrating a component to use SLDS 2.

  • Uplift this component to SLDS 2—list class/token replacements and provide before/after diffs.
  • Create an SLDS 2 migration guide for this component and call out any breaking changes.
  • Generate a step-by-step SLDS 2 uplift checklist for my components with search/replace patterns and sample updates.

See Also