Analyze Salesforce metadata with grounded, read-only org intelligence
sf-intelligence gives AI agents a read-only way to analyze Salesforce metadata: schema, fields, Flows, Apex, permission models, integrations, OmniStudio, and generated documentation from one local org vault.
Last updated 2026-07-29
query a real org vault in 2 minutes - no org, no auth
claude mcp add --transport stdio --scope user sf-intelligence-demo -- npx -y sf-intelligence demoThen ask "give me an overview of this org", "what fields does the Project object have?", "explain the Project__c.Margin_Percent__c formula", or even a misspelling like "where's the paymnet object?" to watch the resolver ask instead of guess. Synthetic "Verdant Energy" org - 12 custom objects, Flows, Apex, profiles, OmniStudio - served fully offline: no Salesforce login, no sf CLI, nothing to configure. more on the demo →
What metadata analysis means here
Most Salesforce search tools stop at file search or raw metadata retrieval. sf-intelligence builds a queryable knowledge base from the retrieved org metadata, then exposes that knowledge through a Salesforce MCP server. The result is plain-language metadata analysis that stays grounded in the org you actually indexed.
Questions this page targets
- "What fields exist on Account, and which are custom?"
- "Which Flows update this field?"
- "What Apex classes reference this object?"
- "Which permission sets grant access to this field?"
- "Generate a data dictionary for this Salesforce org."
- "Explain this org to a new admin or developer."
Metadata families covered
| Area | Examples |
|---|---|
| Schema | Objects, fields, record types, picklists, layouts, tabs |
| Automation | Flows, workflow, approval processes, assignment and escalation rules |
| Code | Apex classes, triggers, call graph, test coverage signals |
| Security | Profiles, permission sets, field-level security, object access, sharing metadata |
| Integrations | Named credentials, remote sites, endpoints, outbound messages, platform events |
| Documentation | Data dictionary, admin handbook, architecture overview, onboarding docs |
Why AI agents need a grounded metadata layer
A general model can explain Salesforce concepts, but it cannot know your org's custom fields, naming conventions, automations, package boundaries, and security model. sf-intelligence does more than dump those facts into the prompt for the model to guess with: every answer is grounded in the metadata you actually retrieved and cited to a canonical component id. And beyond retrieval, a deterministic, org-independent concept model - 143 concepts / 195 rules of general Salesforce truth - reasons over the structure: sfi.interpret joins that model against the graph to match curated structural patterns (master-detail cascade, junction objects, read-only roll-up fields, stacked record-triggered flows) and returns cited, confidence-tiered claims, with no LLM inference and no live call. So Claude, Cursor, Codex, or another MCP client answers from grounded evidence instead of training-data guesses.
Related searches
For blast-radius work, see Salesforce dependency analysis. For client setup, see Claude Salesforce MCP setup. For the complete tool surface, browse all 217 Salesforce MCP tools.
Analyze your org metadata locally.
Install once, run a read-only refresh, then ask metadata questions in plain language.