# Write Salesforce code in Cursor with the org in view. > The SyncOnAI 360 Cursor connector gives Cursor read-only access to your connected Salesforce orgs through a Model Context Protocol server. Cursor can search the org's metadata, look up any component and what depends on it, and read health findings, so the code it writes uses real API names and accounts for what else will be affected. Source: https://synconai360.com/connectors/cursor ## Key facts - **1**: Config block in .cursor/mcp.json - **0**: Write actions available to Cursor - **Every**: Call logged with its tool and token - **Per org**: Token scope you choose ## Why AI code for Salesforce misses the org A project folder holds the code a developer is working on, but rarely the whole org. Cursor writes Apex and components against what it can see, and the org it cannot see is where the surprises are. - **Fields that do not exist.** Generated code references API names that are close to right and fail at deploy. - **Invisible automation.** A trigger is written without knowing the Flows and validation rules that run on the same save. - **Unknown dependents.** Changing a method signature breaks components and classes outside the open project. - **Partial retrieves.** Keeping a full, current copy of the org in the project is slow and goes stale. ## What does Cursor learn about the org? Through the connector, Cursor can search the org's metadata, look up a component and everything that depends on it, list the orgs its token may see and read the findings of a health assessment. It works from SyncOnAI 360's synced copy of the org, which includes the full source of Apex, Flows and Lightning Web Components. Ask Cursor what runs when a Case is saved before writing a trigger, or what calls a method before changing its signature, and it answers from the org rather than from the open files alone. - Org-wide metadata search - Dependencies for any component - Health findings for context ## Can Cursor trust a negative answer? Every answer says how much of the org it was based on. If a search hit its limit or the token can see only some orgs, Cursor is told, so nothing references this method means what it says or is flagged as incomplete. Where source could not be read, such as managed package code hidden by its publisher, that is reported rather than treated as proof that nothing depends on it. - Coverage stated with answers - Hidden package source reported - No silent gaps ## How do you connect Cursor to Salesforce? Create an access token in SyncOnAI 360 under Settings, then Integrations, choose the orgs it may read, and copy it immediately. Add the server address and the token as a bearer header to .cursor/mcp.json in your project, or to the file in your home folder to use it everywhere. Ask Cursor which Salesforce orgs it can see to check the connection, then ask something real about the code in front of you. - One token per machine - Project or global config - Check with a first question ## How does code from Cursor reach the org? The connector is read-only: Cursor cannot deploy, edit or delete anything in an org. Code goes to the org through your normal route, or through SyncOnAI 360, where it becomes a proposal with named checks, its blast radius and a test coverage check, validated against the org before anyone approves. Apex Logic in SyncOnAI 360 refuses edits that would not compile, and a component can be proposed together with its Apex controller and its test as one change. - Read-only by design - Proposals with coverage checks - Component, controller and test together ## How is Cursor's access controlled? Tokens are scoped to the orgs you choose and revoked instantly in Settings. Every call is written to the activity log with the tool and token it used, and each token shows when it was last used; arguments are not recorded. A token is a password: anyone holding it can read the orgs it is scoped to. Keep one per machine and prefer narrow scopes. - Scoped and revocable - Every call logged - One token per machine ## Connecting Cursor 1. **Create a token.** Scope it to the orgs this project touches. 2. **Add the server.** One block in .cursor/mcp.json. 3. **Ask.** What runs on this object? What calls this method? 4. **Ship safely.** Propose the change through checks and approval. ## Salesforce code in Cursor, with and without the org | Without | With SyncOnAI 360 | |---|---| | Close-enough field names | Real API names from the org | | Triggers written blind to Flows | Automation on the object in view | | Signature changes that break callers | Dependents looked up first | | A stale partial retrieve | A synced copy refreshed every six hours | | AI with deploy rights | Read-only, scoped, logged access | ## Who connects Cursor - **Salesforce developers.** Keep Cursor's speed and give it the org's real model, so generated Apex and components fit first time. - **Technical architects.** Ask about dependencies across the whole org from the editor, before a refactor starts. - **Consultancies.** Give developers read access to each client org they work on, scoped per client and revoked at handover. - **Platform owners.** Allow AI coding tools on Salesforce without handing them deploy rights. ## Frequently asked questions ### Can Cursor deploy to Salesforce through this? No. The connector is read-only. Deploy through your normal route, or propose the change in SyncOnAI 360. ### Where does the configuration go? In .cursor/mcp.json in your project, or in the same file in your home folder to use it in every project. ### Does Cursor see our records? No. SyncOnAI 360 keeps metadata, not CRM records, and the connector reads only metadata and findings. ### Does it replace retrieving metadata into the project? For answering questions about the org, yes. You still keep the code you are editing in your project as usual. ### How current is what Cursor sees? The synced copy refreshes every six hours, on demand, and straight after deploys made through SyncOnAI 360. ### Can we restrict it to a sandbox? Yes. Scope the token to the sandbox org only. ### Is every call recorded? Yes, with the tool and token used. The arguments are not recorded. ### Does it work with other editors? Any client that speaks Model Context Protocol over HTTP can connect the same way. ### Is it on every plan? Yes. Every plan includes every feature. ### Can several developers share a token? They can, but one token per machine is better: revoking a lost laptop's token then disturbs nobody else, and the log shows which machine made each call. ### Can Cursor see our Flows? Yes. Flows are part of the synced metadata with their full definition, so Cursor can ask what runs on an object before writing code.