Dylan AndersenDylan Andersen's Docs
Cursor + SalesforceGetting Started with Cursor

MCP Beyond Salesforce

GitHub, Filesystem, Playwright, Context7, Vercel, and other MCPs that round out the SE stack

MCP Beyond Salesforce

The Salesforce MCP is the biggest unlock for SE work, but it's not the only one worth installing. A handful of others turn Cursor from "AI editor with Salesforce tools" into "an agent that can actually do your job end to end."

Read this first

MCPs let agents call tools on your behalf. Install them from sources you trust, scope their access tightly, and read Security & Data Handling before pointing any MCP at a customer org.

The mental model, in one minute

An MCP server is just a process that exposes a set of tools to the agent. The agent sees tool names, descriptions, and schemas, and calls them the same way you'd call an API. Cursor hosts two connection styles:

  • Stdio MCPs run locally as a subprocess. They start when Cursor starts. Most open-source MCPs are stdio.
  • Remote MCPs are HTTP services you authenticate with. Good for SaaS tools where the vendor provides a hosted MCP endpoint.

You choose between them with the command vs. url fields in your .mcp.json.

Where .mcp.json lives

Open it with Cmd+Shift+P on macOS (Ctrl+Shift+P on Windows), then run Cursor: Configure MCP Servers. The file is a single JSON object:

{
  "mcpServers": {
    "Salesforce DX": { "command": "npx", "args": ["..."] },
    "GitHub": { "command": "npx", "args": ["..."] }
  }
}

Names are yours to choose. Pick names that tell the agent what the server is for.

The MCPs worth having

GitHub

Pull request creation, issue triage, release notes, reading other team members' PRs. Two paths:

GitHub ships an official hosted MCP. Authenticate via OAuth:

{
  "mcpServers": {
    "GitHub": {
      "url": "https://api.githubcopilot.com/mcp/"
    }
  }
}

When Cursor starts, it prompts you to authorize. The access follows your GitHub permissions.

A local server that uses a personal access token:

{
  "mcpServers": {
    "GitHub": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"],
      "env": {
        "GITHUB_PERSONAL_ACCESS_TOKEN": "ghp_..."
      }
    }
  }
}

Store the token in a secret manager or environment file, not in .mcp.json committed to a repo. Better: use the remote variant if your org allows it.

Things the GitHub MCP is great for:

  • "Draft a PR body from the commits on this branch."
  • "Find every open issue labeled agentforce-poc and summarize them."
  • "Create a release note for the changes since v1.3."

Filesystem

Lets the agent read and write files outside the current Cursor workspace. Useful when you have a reference library of past POCs or a shared customer folder you want the agent to pull from.

{
  "mcpServers": {
    "Customer Library": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-filesystem",
        "/Users/dylan/customer-workspaces"
      ]
    }
  }
}

Always scope it. The final argument is the path the server is allowed to see. Never give it / or ~.

Playwright or Browser MCP

Lets the agent open a real browser, render a page, and click through it. For SE work, this is how you verify a freshly deployed Lightning page actually renders:

{
  "mcpServers": {
    "Playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

A short prompt that exercises it:

Use the Playwright MCP to open my org's sandbox, log in, navigate to the
Accounts tab, open the first account, and tell me whether my new LWC
appears on the record page. Take a screenshot for proof.

Great for visual regression checks, demo rehearsals, and answering "did the deploy actually land?" without switching windows.

Context7 (or an equivalent docs MCP)

Keeps Salesforce developer documentation fresh in the agent's hands. Rather than the agent guessing an API shape from a training cutoff, it pulls the current docs.

{
  "mcpServers": {
    "Context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    }
  }
}

Usage pattern in chat:

Use Context7 to look up the Salesforce Data 360 ingestion API current
shape, then write the fetch call.

Vercel

If your POC includes a companion Next.js or React app (custom front end, marketing page, hosted demo UI), the Vercel MCP lets the agent deploy, inspect logs, and manage environment variables directly.

{
  "mcpServers": {
    "Vercel": {
      "url": "https://mcp.vercel.com/"
    }
  }
}

Typical uses:

  • "Create a preview deployment from this branch and share the URL with me."
  • "Check the latest production log for errors involving the Salesforce callout."
  • "Rotate the SF_CLIENT_SECRET environment variable in the prod environment."

Data 360 specifics

Data 360 is reachable through the standard Salesforce MCP with the right toolsets. For sf data360 CLI flows, the sf-datacloud-retrieve, sf-datacloud-segment, and related skills give the agent deep context on the commands. Combine them: Salesforce MCP for execution, the Data 360 skills for the playbook.

Installing, testing, and trusting a new MCP

A short loop:

  1. Read the MCP's README. Check what tools it exposes. Default-deny any MCP that can "execute arbitrary commands" without limits.
  2. Add it to .mcp.json with the narrowest possible scope.
  3. Restart Cursor.
  4. Open the MCP status view (in Cursor's settings, or via the chat panel's MCP indicator) and confirm it connected.
  5. Ask the agent "list the tools you have from the <name> MCP" and read the response.
  6. Test one safe call before trusting it with anything real.

Remote vs. stdio, at a glance

AspectStdioRemote
Installnpx starts it locallyURL in .mcp.json, OAuth on first use
AuthToken in env vars or credentials fileStandard OAuth
OfflineWorks offlineNeeds network
PerformanceFast, no round tripDepends on the service
UpgradesPinned via npm versionThe service upgrades on its own
Security postureWhatever your machine hasWhatever the vendor has

For customer-facing work, remote MCPs with proper OAuth are usually the cleaner choice because they don't require you to store long-lived tokens on disk. For local convenience tools (Filesystem, Playwright), stdio is simpler.

A realistic SE .mcp.json

A config that covers most SE work:

{
  "mcpServers": {
    "Salesforce DX": {
      "command": "npx",
      "args": [
        "-y", "@salesforce/mcp@latest",
        "--orgs", "DEFAULT_TARGET_ORG",
        "--toolsets", "orgs,metadata,data,users"
      ]
    },
    "GitHub": {
      "url": "https://api.githubcopilot.com/mcp/"
    },
    "Context7": {
      "command": "npx",
      "args": ["-y", "@upstash/context7-mcp"]
    },
    "Playwright": {
      "command": "npx",
      "args": ["-y", "@playwright/mcp@latest"]
    }
  }
}

Add a scoped Filesystem MCP if you need agent access to a reference library, and swap in per-customer Salesforce MCPs on customer engagements (see Multi-Org Workflows).

What to do next

On this page