This is a thin jsforce bridge rather than a product: two entry points, two environment variables, no published package and no OAuth flow. That makes it quick to read and quick to modify if you want a specific set of Salesforce calls, and a poor fit if you want something to drop in and forget. A username and password authenticate it, so what it holds is a full user account.
A small MCP server that puts the Salesforce API in front of an assistant through `jsforce`. It is deliberately minimal: you build it from the repository and run one of two entry points, depending on the transport your client speaks.
- The Salesforce API reached through `jsforce`, the established JavaScript Salesforce client
- Two transports from the same build — `build/stdio.js` for clients that spawn a local process, `build/streamable.js` for Streamable HTTP
- Credentials kept to two environment variables, so they can live in the client's `env` block rather than your shell — `SALESFORCE_USERNAME`, `SALESFORCE_PASSWORD`
- Connect it once and read the tool list from your client: the repository specifies the transports and the credentials, and leaves the call list to the running server
Node, and a build from source — there is no published package. `git clone`, `npm install`, `npm build`, then `node build/stdio.js` for stdio or `node build/streamable.js` for Streamable HTTP. Authentication is a Salesforce username and password supplied as `SALESFORCE_USERNAME` and `SALESFORCE_PASSWORD`, exported in the shell or set in the client's `env` block; the documented Claude Desktop entry runs `node` against an absolute path to `build/stdio.js`.