Salesforce MCP: How the FUSE Integration Actually Works

2026-07-27

How FUSE's Salesforce MCP integration works: read-only by three mechanisms, six tools, custom object support, and result caps that protect the context window.

FUSE's Salesforce MCP integration is read-only, and read-only limits what it changes rather than what it reaches. It traverses standard objects, custom objects, custom fields and the relationships between records, including the parent-child paths an enterprise pipeline is built from, through six read-only tools, with Salesforce executing every query on its own infrastructure. What it does not do is write: no create, update or delete, and no copy of your CRM.

Most write-ups of Salesforce MCP stop at "connect it and ask questions." That is the easy half. The hard half is what happens when an org with four hundred custom fields meets a model with a finite context window, and nothing re-checks the number that comes out.

This is how the integration is actually built, specific enough to argue with.

What It Does and Does Not Do

Read-only limits what FUSE can change, not what it can reach. Those are unrelated properties, and conflating them is the most common misreading of this integration.

What it reaches is the whole structure: standard objects, custom objects, custom fields, and the relationships between records, including the parent-child paths a real enterprise pipeline is built from. sf_get_related_records walks those relationships directly, and Salesforce executes relationship queries against whatever your org contains. A pipeline running on custom stages, custom objects and renamed fields reads the same as a stock one. FUSE discovers that structure live rather than from a stored model, so an object your admin added last week is visible on the next question.

What it does not do is write. No create, no update, no delete, no operational sync. It is not an ETL pipeline and it does not stage your CRM in a warehouse. FUSE's Salesforce sync refreshes exactly two things, your org name and your edition, and pulls no CRM records at all.

If you need write-back, pipeline orchestration or scheduled record updates, this is the wrong tool.

FUSE Is the Client. Salesforce Is the Runtime.

FUSE does not host a Salesforce MCP server. It is a client of Salesforce's own, using the standard MCP Python SDK over streamable HTTP against api.salesforce.com/platform/mcp/v1/platform/sobject-reads.

That endpoint carries most of the security story. It is Salesforce's read-only SObject server and the only one FUSE ever connects to. The connection targets the central Salesforce gateway rather than your org's instance_url, and the transport refuses any URL that is not HTTPS on a salesforce.com or force.com host, so a misconfigured environment variable fails closed.

The consequence is that FUSE never runs code inside your org and never composes SOQL in some hidden query planner. The model writes the SOQL, Salesforce executes it and enforces its own object and field-level security, and a result comes back. There is no SOQL parser in the FUSE codebase to audit, because there is no SOQL execution in FUSE.

The Six Tools

Salesforce's read-only server exposes six tools. FUSE renames each with an sf_ prefix, because query collides across the dozen-odd MCP servers FUSE runs at once, and rewrites all six vendor descriptions:

Each rewritten description follows a fixed USE FOR / DO NOT USE FOR / ARGUMENTS shape. Not cosmetic: a model choosing among twelve servers' worth of tools picks badly when descriptions are vague, and the common failure is a wrong tool rather than a wrong answer.

Read-Only Is Three Separate Mechanisms

Anyone can claim read-only. Here is what holds the line, and note that two of the three are not FUSE's to overrule.

The OAuth scopes FUSE requests are mcp_api and refresh_token. The broad api scope, which grants read and write across the REST API, is deliberately not requested. That choice has a cost FUSE chose to pay: an org-metadata lookup that would have been a simple REST call had to be rebuilt to run through MCP, because without api scope the REST path returns 401 in production.

The server is platform/sobject-reads, which offers no mutating tool. And SOQL itself has no write statements.

One caveat for anyone auditing this: FUSE keeps no runtime allowlist of tool names. It exposes whatever tools/list returns, so a seventh tool on the read-only server would surface automatically. A unit test catches that at build time, not at runtime.

Whose Permissions the Query Runs Under

This is the question enterprise buyers actually ask, and it deserves a precise answer rather than a comfortable one.

Queries execute as one Salesforce user: the account that authorized the connection for your team, not the individual asking the question in FUSE. FUSE resolves a single team-level credential and reuses it across that workspace.

So FUSE sees exactly what the connected login can see and not one field more. If that login cannot open a record today, neither can FUSE, and nothing widens because someone asked a question. But if you are picturing each FUSE user's own Salesforce permissions applying to their own questions, that is not what happens. Scope the connecting account accordingly.

Every call is attributed to that user in standard Salesforce audit logs, and you can isolate the traffic in Event Monitoring by filtering for APICLIENTCATEGORY = SALESFORCE_HOSTED_MCP. Authorization uses the OAuth authorization code flow with PKCE, the only path Salesforce supports here, so there are no service accounts and no machine-to-machine flow.

Keeping a Real Org Out of the Context Window

This is where generic connectors fall over, and it is mostly an engineering problem rather than a prompting one.

Results are capped twice. A tool call returns at most 5,000 rows, and the serialized payload is capped at 100,000 bytes, measured across the JSON rows and the rendered table together rather than either in isolation. Exceed a cap and the model receives a 50-row preview plus the true row count, the number withheld, and an explicit instruction not to invent the remainder. That last part matters: a truncated result that does not announce itself is how a model ends up confidently summarizing rows it never saw.

Schema is the other pressure point. A full describe on every object in a large org is exactly the request that blows a context window, so sf_get_object_schema called with no arguments returns an org-wide index instead, roughly 80 to 90 percent smaller than describing objects individually, and the model narrows from there. Describes are cached 24 hours per org and object.

Columns of raw record IDs are dropped from the rendered table too, because they cost tokens and tell a human nothing.

Custom Objects

Nothing in FUSE enumerates a fixed list of supported objects, so the handling worth knowing is in the labels. A field named Lift_App_Opens_Pct__c renders as "CTV Lift: App Opens %" when that is the label your admin set. Without a describe, the fallback strips the __c suffix and splits the name into words, degrading to "Lift App Opens Pct" rather than showing raw API names. Polymorphic columns, the kind a mixed-object search or a Task.Who reference produces, fall back to mechanical labels rather than stamping the wrong object's label on a column.

What a Query Actually Does

Take "which enterprise deals slipped out of this quarter, and what were they worth."

The agent calls sf_get_object_schema with no arguments, narrows to Opportunity, writes SOQL filtering on stage, close date and record type, and Salesforce executes it. The result returns with your real field labels applied, ID columns pruned, and the payload checked against both caps.

Then the numbers get re-derived. Emet, the verification layer now running on FUSE analysis, recomputes the figures against the source rather than asking the model whether it was right, and a total that does not reconcile is corrected before you read it.

Why a Raw MCP Connection Is Not Enough

Point a frontier model straight at a Salesforce MCP server and three things break.

The schema arrives before the question does. A large org's describe output crowds out the reasoning, and the model starts economizing on which fields it reads.

Then the failure mode gets quiet. On Berkeley's Data Agent Benchmark, untuned frontier agents score under 50 percent on realistic data questions, and around 85 percent of wrong answers come from bad planning or implementation rather than pulling the wrong data. The model finds the right records and still computes the wrong thing. Nothing in a raw MCP connection re-checks that.

Third, CRM text is user-authored, which makes it an injection surface. Every result FUSE returns is wrapped in an envelope marked untrusted with a per-call random boundary, so text in an opportunity description cannot impersonate an instruction.

Access was never the hard part. Translation and verification are.

Frequently Asked Questions

Is FUSE's Salesforce integration read-only?

Yes. Three separate mechanisms enforce it: FUSE requests only the mcp_api and refresh_token OAuth scopes and never the broad api scope, it connects only to Salesforce's read-only platform/sobject-reads server, and SOQL has no write statements. FUSE cannot create, update or delete a record.

Can FUSE map complex Salesforce pipelines and custom objects?

Yes. FUSE traverses custom objects, custom fields and the relationships between records, including the parent-child paths a pipeline is built from, and it discovers that structure live rather than from a stored model. Read-only constrains what FUSE writes, not how deeply it reads.

Does FUSE work with custom Salesforce objects?

Yes, including custom fields. Nothing in FUSE hardcodes a list of supported objects, so the agent queries whatever your org contains. Custom field labels come from your org's schema, so a field your admin renamed displays with that name rather than its API name.

Whose Salesforce permissions does FUSE use?

Queries run as the Salesforce account that authorized the connection for your team, not as the individual asking the question. FUSE sees exactly what that login can see and nothing more. Scope the connecting account to the access you want FUSE to have.

How is FUSE different from Salesforce Agentforce?

Agentforce is built for autonomous and customer-facing work inside the Salesforce platform, and it can act. FUSE is read-only analysis whose distinguishing property is that Salesforce sits alongside your other sources. Agentforce reaches Salesforce data; it does not reach GA4, Google Ads, Meta or Shopify.

How is FUSE different from Claudeforce?

Claudeforce, announced in August 2026, brings Salesforce into Claude with prebuilt sales skills and can update records. It is Salesforce-centric and write-capable. FUSE is read-only and cross-source: one question spanning CRM, ad platforms and analytics, with the resulting figures verified. Different problems, and a revenue team could run both.

Does FUSE copy my Salesforce data?

No. There is no nightly sync of records, no warehouse and no second copy. FUSE's Salesforce sync refreshes only your org name and edition. Every CRM fact in an answer was fetched live from Salesforce during that turn.

Which Salesforce edition do I need?

Enterprise Edition or above, a Salesforce requirement for Hosted MCP rather than a FUSE one. Hosted MCP has been generally available since April 2026, and Salesforce is available on all paid FUSE plans.

For a less technical walkthrough, see how to never log into Salesforce again.