The 78 tools follow the platform's own seams: SObject rows and describes on REST, Apex execution and test runs on Tooling, accounts and contacts on GraphQL, sandboxes on their own. Authentication is a family in its own right — device flow, JWT bearer, client credentials and SOAP login are each callable — which is unusual on a server that already reads a token from the environment. Some query tools are fixed rather than parameterised: fetch_contacts, query_accounts and fetch_opportunities_not_closed take no arguments, so they return what their author wrote rather than what you ask for.
A 78-tool Salesforce server spanning the REST SObject rows, the Tooling API, the GraphQL endpoint, the OAuth 2.0 flows and the sandbox records of a single org.
- SOQL queries plus per-record reads, creates, deletes and external-ID upserts against any SObject API name
- Tooling API work: anonymous Apex execution, synchronous and asynchronous test runs, tooling queries and Apex code completions
- Metadata on demand — global and per-object describes, compact, named and approval layouts, quick actions, and the records changed or deleted between two timestamps
- GraphQL reads over accounts and contacts, with cursor pagination, a filter argument and an introspection query, alongside account create, update and delete
- Salesforce's OAuth 2.0 flows as individual tools — web server, user agent, device, JWT bearer, client credentials, asset token and SOAP login — with token refresh, revocation and introspection
- Sandbox records listed, fetched, status-checked, refreshed, cloned and deleted
- Binary payloads out of records: blob fields, rich-text images and files by ID
A Salesforce org at SALESFORCE_ENDPOINT, an access token in SALESFORCE_ACCESS_TOKEN and a PORT value — three environment variables. Every tool addresses objects by their API name, so what the org returns is bounded by that token's permissions.
One command plus a key — npx @rapidocloud/mcp-force run-server, then supply credentials