sf-intelligence vs Salesforce DX MCP Server

At a glance

	sf-intelligence	Salesforce DX MCP Server
Maintainer	Community (MIT + Commons Clause)	Salesforce (official)
Primary purpose	Understand an org - impact, permissions, docs	DevOps - deploy, retrieve, run code
Write to org	No - read-only retrieve only	Yes - deploy, edit, run Apex/tests
Default mode	Offline (local vault)	Live API per tool call
Dependency graph	Yes - DuckDB, confidence-tagged edges	No dedicated graph
Impact / blast radius	Core feature	Not a focus
Permission tracing	Yes - FLS, sharing cascade	Limited
Plain-language routing	Deterministic intent router	Tool-per-task model
Cost	Free	Free (official)
npm package	sf-intelligence	@salesforce/mcp (via Salesforce CLI)

Choose sf-intelligence when you need to…

• Ask "what breaks if I delete this field?" before making a change
• Trace why a user cannot see a record or edit a field
• Document an inherited org (data dictionary, architecture overview)
• Explore a production org with zero write risk
• Work offline after a single retrieve (airplane, VPN-restricted environments)
• Get provenance and confidence labels on every answer

Choose the DX MCP Server when you need to…

• Deploy or retrieve metadata from an AI-assisted workflow
• Run Apex, execute tests, scaffold LWC
• Use first-party Salesforce DevOps tooling in MCP

Use both together

A common pattern: use sf-intelligence to understand the blast radius and permissions landscape, then use the DX MCP Server to implement the change. Register both MCP servers in the same Claude Code or Cursor project - they do not conflict.